Location = precedence breakage

Server NGINX
1

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?

Posted at Nginx Forum:

2

Ugh. Sorry to reply to own post, but forum ate square brackets and
changed meaning in mail archive. It should have said like this:

This worked consistently in 0.7.6x (and according to the docs, it should work):

location = /base { (some stuff) }
location ^~ /base { (different stuff) }

Apologies.

Posted at Nginx Forum:

3

On Wed, Dec 16, 2009 at 08:48:38AM -0500, kyleb wrote:

…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.

–
Igor S.
http://sysoev.ru/en/

4

On Wed, Dec 16, 2009 at 09:19:55AM -0500, kyleb wrote:

On testing 0.8.30, accessing http://my.server/base works, but
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” ?

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 S.
http://sysoev.ru/en/

5

On Wed, 16 Dec 2009 10:01:00 -0500, Igor S. wrote:

What is the “socket error” ?

The kind produced by sending packets to non-existent host, as caused by
bone-headed stupid mistake I made. Not that it helps, but I deeply
apologize to have wasted your time.

In case of curiosity or desire to know truth:

CGI hardcoded hostname for URLs. (Mistake #1: Bad/lazy design.) Old
test server had entry in hosts file, thus lookup returned IP address
instead of NXDOMAIN. New test server has different name/ip. When I
test following dummy links from base page, user-agent waits awhile, then
says ``socket error’’ (actual cause: TCP SYN goes out, nothing comes
back).

Since only difference (I thought) is in nginx version and two nginx.conf
location blocks, I focus on that without looking at hostname in address
bar. (More mistakes: Snap judgments and failure to attend too-obvious
details.) I spend about 10-20 minutes trying all different nginx
options, then hit mailing list.

I find error after you ask what socket error is, and try different
user-agent from different host with more debugging ability. No entry in
hosts file there; now I get NXDOMAIN, which points me to error. I fix
CGI, and everything works perfectly. nginx is innocent.

I am very severe against people for exactly this kind of mistake. I
hang my head in shame, now. At least you should know the truth (painful
as it is for me to say it), and not waste any more valuable time on it.

Posted at Nginx Forum:

6

On Wed, 16 Dec 2009 08:57:53 -0500, Igor S. wrote:

hangs for awhile, then returns a socket error. I even tried

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.

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?

Thanks again.

Posted at Nginx Forum: