# Location = precedence breakage

**URL:** <https://www.ruby-forum.com/t/location-precedence-breakage/180456>\
**Category:** NGINX\
**Created:** [December 19, 2009, 3:25pm UTC](https://www.ruby-forum.com/t/location-precedence-breakage/180456 "2009-12-19T15:25:41Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![kyleb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/278dde/32.png) [@kyleb](https://www.ruby-forum.com/u/kyleb)\
**Post date:** [December 19, 2009, 3:25pm UTC](https://www.ruby-forum.com/t/location-precedence-breakage/180456/1 "2009-12-19T15:25:41Z")

</div>

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](http://my.server/base) works, but  
[http://my.server/base/plus/long/path/used.by.application](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:

> **[location = precedence breakage](https://forum.nginx.org/read.php?2,30889,30889#msg-30889)**
>
> This worked consistently in 0.7.6x (and according to the docs, it should work): location = /base { \[stuff\] } location ^~ /base { \[different stuff\] } On testing 0.8.30, accessing http://my.server/base works, but...

---

<div class="post-metadata">

**Author:** ![kyleb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/278dde/32.png) [@kyleb](https://www.ruby-forum.com/u/kyleb)\
**Post date:** [December 19, 2009, 3:25pm UTC](https://www.ruby-forum.com/t/location-precedence-breakage/180456/2 "2009-12-19T15:25:41Z")

</div>

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:  
[http://forum.nginx.org/read.php?2,30889,30891#msg-30891](http://forum.nginx.org/read.php?2,30889,30891#msg-30891)

---

<div class="post-metadata">

**Author:** ![kyleb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/278dde/32.png) [@kyleb](https://www.ruby-forum.com/u/kyleb)\
**Post date:** [December 19, 2009, 3:25pm UTC](https://www.ruby-forum.com/t/location-precedence-breakage/180456/3 "2009-12-19T15:25:41Z")

</div>

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.

> **[Igor Sysoev](http://sysoev.ru/en/)**

---

<div class="post-metadata">

**Author:** ![kyleb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/278dde/32.png) [@kyleb](https://www.ruby-forum.com/u/kyleb)\
**Post date:** [December 19, 2009, 3:25pm UTC](https://www.ruby-forum.com/t/location-precedence-breakage/180456/4 "2009-12-19T15:25:41Z")

</div>

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

> > > On testing 0.8.30, accessing [http://my.server/base](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.

> **[Igor Sysoev](http://sysoev.ru/en/)**

---

<div class="post-metadata">

**Author:** ![kyleb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/278dde/32.png) [@kyleb](https://www.ruby-forum.com/u/kyleb)\
**Post date:** [December 19, 2009, 3:25pm UTC](https://www.ruby-forum.com/t/location-precedence-breakage/180456/5 "2009-12-19T15:25:41Z")

</div>

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:  
[http://forum.nginx.org/read.php?2,30889,30951#msg-30951](http://forum.nginx.org/read.php?2,30889,30951#msg-30951)

---

<div class="post-metadata">

**Author:** ![kyleb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/278dde/32.png) [@kyleb](https://www.ruby-forum.com/u/kyleb)\
**Post date:** [December 19, 2009, 3:25pm UTC](https://www.ruby-forum.com/t/location-precedence-breakage/180456/6 "2009-12-19T15:25:41Z")

</div>

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:  
[http://forum.nginx.org/read.php?2,30889,30905#msg-30905](http://forum.nginx.org/read.php?2,30889,30905#msg-30905)