location = precedence breakage
Igor Sysoev
igor at sysoev.ru
Wed Dec 16 18:01:00 MSK 2009
On Wed, Dec 16, 2009 at 09:19:55AM -0500, kyleb wrote:
> On Wed, 16 Dec 2009 08:57:53 -0500, Igor Sysoev wrote:
>
> > On Wed, Dec 16, 2009 at 08:48:38AM -0500, kyleb wrote:
> >
> >> This worked consistently in 0.7.6x (and according to the docs, it
> >> should work):
> >>
> >> location = /base { }
> >> location ^~ /base { }
> >>
> >> On testing 0.8.30, accessing http://my.server/base works, but
> >> http://my.server/base/plus/long/path/used.by.application
> >> hangs for awhile, then returns a socket error. I even tried
> >> differentiating configuration with trailing slash:
> >>
> >> location ^~ /base/ { }
> >>
> >> ...but apparently, the same results.
> >>
> >> Logs show nothing. The access with the longer path doesn't show up in
> >> logs at all (not access, not error). I don't have debug build on hand
> >> right now, maybe I will compile one later if I have time. No crash,
> >> nginx stays up, but request utterly fails.
> >>
> >> Any changes to location resolving code that would break the precedence
> >> between = and other operators, resulting in nginx to be confused?
> >
> > It should work. The problem is not in locations.
>
> Thank you for response. Exactly same config files were used previously in 0.7.6x, and worked beautifully. Now, socket error with nothing in logs. This is why I suspect nginx bug.
What is the "socket error" ?
> Here is less minimal config (exactly as I use, with only paths changed):
>
> location = /humans.keep.out {
> expires epoch;
> fastcgi_param SCRIPT_FILENAME /path/to/tarpit/cgi;
> include my.fastcgi.conf;#fairly basic stuff
> }
> location ^~ /humans.keep.out {
> expires epoch;
> fastcgi_param SCRIPT_FILENAME /path/to/tarpit/cgi;
> include my.fastcgi.conf;#fairly basic stuff
> limit_rate 300; #have tried commenting this out. No difference.
> }
>
> As you can see, there is no difference to cgi script (which simply generates infinite URL space and poison e-mail addresses). Even if CGI was problem, nginx should return bad-gateway HTTP response (not socket error and drop connection without logging).
>
> As you can see also, even *identical* location blocks result in same error.
>
> Besides debug build (which I will maybe try to make later), any suggestions/help to track down problem?
Yes.
--
Igor Sysoev
http://sysoev.ru/en/
More information about the nginx
mailing list