On Wed, Apr 30, 2014 at 03:04:11AM -0400, kay wrote:
[…]
So it seems that error_page 405 /error.html rewrites $request_method
Yes, redirection a request to an error page implies changing the
request method to GET (unless it’s HEAD). It’s required to
properly return error page. Much like with URI change, this can
be avoided by using a redirect to a named location instead.
Will you elaborate your problem and use case? Preferably with a
minimal but still complete example to demonstrate your intention and
problem. As the author of the ngx_memc module, I’d like to have to
look (and find a solution for you)
Sure, you can use nginx.conf from my previous message and this server
config:
I’ve noticed 2 obvious mistakes in your config. See blow.
server {
listen 80;
rewrite_by_lua ’
local res = ngx.location.capture(“/memc?cmd=get&key=test”)
ngx.say(res.body)
';
It is not recommended to use the rewrite_by_lua directive directly
in the server {} block. Because this rewrite_by_lua directive will
just get inherited by every location in that server {} block by
default, including 1) your location /memc, which will create a
subrequest loop because you initiate a subrequest in your
rewrite_by_lua code to /memc, and 2) your error pages like
/error.html. And I’m sure this is not what you want.
If you generate a response in rewrite_by_lua by calls like
“ngx.say()”, then you should really terminate the current request
immediately, via “ngx.exit(200)” or something like that, otherwise
nginx will continue to run later phases like the “content phase”
(which is supposed to generate a response) and you will face duplicate
responses for the same request.
Another suggestion is to check out your nginx error logs for hints (if
any). If the existing info is not enough, you can further enable
nginx’s debugging logs: A debugging log
Finally, ensure your version of ngx_lua, ngx_memc, and the nginx core
are recent enough.
Sure, you can use nginx.conf from my previous message and this server
config:
server {
listen 80;
rewrite_by_lua ’
local res = ngx.location.capture(“/memc?cmd=get&key=test”)
ngx.say(res.body)
';
location / {
root /etc/nginx/www;
}
location /memc {
internal;
access_log /var/log/nginx/memc_log main;
log_subrequest on;
set $memc_key $arg_key;
set $memc_cmd $arg_cmd;
memc_cmds_allowed get;
memc_pass vmembase-2:11211;
}
}
If you enable “error_page 405 /error.html;” nginx will hang on “curl -X
TRACE localhost”
If you disable “error_page 405 /error.html;” - everything will be fine.
It is not recommended to use the rewrite_by_lua directive directly
You can do the same with access_by_lua
Please do not cut my original sentence and just pick the first half.
The full sentence is “it is not recommended to use the rewrite_by_lua
directive directly in the server {} block.” and the reason follows
that. The same statement also applies to access_by_lua.
Also, please read the full text of my previous email and correct all
the things I listed there.
I’ve tried your nginx config snippet on my side with nginx 1.7.0 +
ngx_memc 0.14 + ngx_lua 0.9.7. And I cannot reproduce any hang on my
side. Without further details I’m afraid I cannot really help.
Several suggestions:
check out your nginx error log for any hints regarding your
configuration issues or memcached backend issues or something.
try to construct a minimal but still complete example that can
help reproducing the issue you’re seeing in others’ boxes, preferably
with precise steps.
try to enable the nginx debugging logs for more details for your
problematic request: A debugging log If
you do not understand the debugging logs, you can put it somewhere on
the web (like GitHub Gist) and provide the link here.
Okay, I can reproduce your request hang on my side now and I see what
is going on here.
Basically the 405 error is thrown so early in the processing flow of
your TRACE request within the nginx core that you cannot do
complicated processing like initiating a subrequest in your error page
target (because the request state has not been fully initialized).
Several suggestions:
prevent complicated logic (like subrequests and etc) in your error
page target location,
avoid using error_page directives in big scope as server {} or even
http {} because every location will inherit your error_page
configurations, including your location /memc for subrequests, which
can create an access dead loop.
On Fri, May 16, 2014 at 01:25:57PM -0700, Yichun Z. (agentzh) wrote:
processing lifetime (like when processing the request header).
Because it should be done in the nginx core, and I can do very little
on my 3rd-party modules side about this.
Maxim D.: what is your opinion on this?
First of all, I think that people should think before specifying
error processing, especially complex error processing.
It is known that using subrequest for errors generated early may
cause request hang (and FengGu tried to provide a patch
a while ago on nginx-devel@), and it will be eventually fixed.
This is relatively low priority though, see above.
First of all, I think that people should think before specifying
error processing, especially complex error processing.
Unfortunately we cannot control what the users think Many users
just try things away according to their intuition. I’d expect that
we’ll have to waste more time to explain to other users trying to do
this in the near future (before it gets fixed). I already cannot
remember exactly how many times my modules’ users have reported such
things in the past
IMHO, if nginx cannot handle a particular case, it should complain
about it rather than hang forever. It is about usability
It is known that using subrequest for errors generated early may
cause request hang (and FengGu tried to provide a patch
a while ago on nginx-devel@), and it will be eventually fixed.
That’s cool. Looking forward to that.
Regards,
-agentzh
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Many users