Hi igor,
I've made a patch for this bug. What do you think ?
++ jerome
Le 18 février 2010 11:48, Jérôme Loyet <jerome(a)loyet.net> a écrit :
> Hi,
>
> I have a strange behaviour, I think it's a bug.
>
> I have set nginx as a frontend to apache using proxy_pass. I also set
> up proxy_cache to cache everyhting from the proxy:
>
> log_format my_combined '$remote_addr - $remote_user [$time_local]
> "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent"
> $request_time $upstream_cache_status';
> server {
> ...
> access_log /var/log/nginx/access my_combined;
> proxy_cache cache1;
>
> location / {
> proxy_cache_valid any 5m;
> proxy_pass http://backend.www;
> }
> }
>
> To exclude some pages from being cached, I'm adding the
> "X-Accel-Expires: 0" in the response from the backend.It works as
> those pages are marked as MISS in the access log (MISS and HIT when
> X-Accel-Expires is not set).
>
> But, when the page is not cached (with X-Accel-Expires) some headers
> are hidden as if the page was cached.
>
>
> Here is some example:
>
> The backend set these headers:
>
> Set-Cookie: PHPSESSID=bd01a429e06336b883d36d6633a04917; path=/
> Content-Length: 11
>
> The client receives:
> Content-Length: 11
>
> As the page is cached, the Set-Cookie header is removed.
>
> Then if the backend add the X-Accel-Expires header:
>
> Set-Cookie: PHPSESSID=bd01a429e06336b883d36d6633a04917; path=/
> Content-Length: 11
> X-Accel-Expires: 0
>
> The clients receives:
> Content-Length: 11
>
>
> The page is not cached (thanks to X-Accel-Expires: 0) but the
> Set-Cookie headers has been removed without any reasons.
>
> This bug exists because the list of headers to remove are set when the
> conf is loaded (ngx_http_proxy_merge_loc_conf in
> http/modules/ngx_http_proxy_module.c at line 2256) and it should be
> done dynamicaly for each requests.
>
Hello!
Here are some patches I've posted recently in mailing lists
in response to bug reports, nothing new.
Posting here to make sure they aren't lost and hopefully get
review and/or will be committed.
Maxim Dounin
In ngx_http_subrequest, the newly initialized subrequest's
unparsed_uri is set to the same value as the parent request's
unparsed_uri. (I'm looking at 0.8.33.)
This interacts in a bad way with the proxy module. The proxy code
that builds the request to the upstream, in ngx_http_proxy_eval, uses
the subrequest's unparsed_uri, rather than its uri.
The result is that, if a request for /prefix/foo creates a subrequest
for /prefix/bar, and the server has been configured to proxy /prefix/*
to some upstream, the subrequest will result in an upstream request
for /prefix/foo (the same URI as the parent request) rather than
/prefix/foo.
Is that a bug, or is it the intended behavior?
Thanks,
Brian
Hi everyone,
I'm attempting to implement a module which generates a "request id (rid)"
variable. It's basically a uuid. The special requirement I have is that this
variable (call it $request_id) needs to be different per-request, but also
contain the same value if referenced multiple times in that request. For
example, I will use the variable in both a log_format directive as well as
a proxy_set_header directive. (Obviously the id is to log a request id that
can be used to correlated frontend requests to activity/exceptions on the
backends). So obviously I want to $request_id to be the same in log_format
and proxy_set_header, but at the same time different for every request.
I have the basic functionality of the variable working, but what I can't
figure out how to do is to keep the value the same during a single request.
Right now every time $request_is used, by get_handler is invoked and i
generated new uuid.
Is there some way of indicating the variable should be cached the request
scope, or is there somewhere I can store the variable in ngx_http_request_t*
for later retrieval?
I'll be releasing this project on github once I can complete this piece of
the functionality.
Thanks,
Brian
# HG changeset patch
# User Maxim Dounin <mdounin(a)mdounin.ru>
# Date 1266634085 -10800
# Node ID dd5526e935d256a3f8c55e5ffde9890d1e1e4a8d
# Parent 0f0a551e29c08abf4a01d255be44e421d581f7b7
Variables: honor no_cacheable for not_found variables.
Variables with not_found flag set follow the same rules as ones with valid
flag set. Make sure ngx_http_get_flushed_variable() will flush non-cacheable
variables with not_found flag set.
This fixes at least one known problem with $args not available in subrequest
(with args) when there were no args in main request and $args variable was
queried in main request (reported by Laurence Rowe aka elro on irc).
Also eliminate unneeded call to ngx_http_get_indexed_variable() in cacheable
case (as it will return cached value anyway).
diff --git a/src/http/ngx_http_variables.c b/src/http/ngx_http_variables.c
--- a/src/http/ngx_http_variables.c
+++ b/src/http/ngx_http_variables.c
@@ -426,7 +426,7 @@ ngx_http_get_flushed_variable(ngx_http_r
v = &r->variables[index];
- if (v->valid) {
+ if (v->valid || v->not_found) {
if (!v->no_cacheable) {
return v;
}
If an HTTP response has a Content-Type with a charset, like this:
Content-Type: text/html; charset=utf-8
the ngx_http_test_content_type function tries to match the entire
header value, including the "charset=utf-8" part, against the supplied
types hash. If the hash contains just "text/html" the "text/html;
charset=utf-8" won't match, and ngx_http_test_content_type will return
null.
Is that intentional, or should ngx_http_test_content_type only
consider the part of the content-type before the ';'?
I can think of arguments both for and against the current behavior,
but my question is: is this behavior considered intentional, or is it
a bug?
Thanks,
-Brian
Hi,
there is a small bug in nginx-0.8.33 in ngx_http_variables.c in line 497.
Should be 14 there.
I wrote an alternative mod_rewrite module for Apache, which in the response
set header X-Accel-Redirect.
I also set X-Path-Info there.
In the nginx.conf I tried to set:
fastcgi_param PATH_INFO $upstream_http_x_path_info; # but
$upstream_http_x_path_info is empty. Why?
How could I set PATH_INFO without patching nginx, to the value of the
X-Path-Info header got from proxy?