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