preventing rewrite loops with "index"

[Marcus Clyne]

Hi,

Maxim Dounin wrote:
>>
>> The example is obviously correct, but it doesn't truly explain the
>> reason for getting the 404 for accessing /users/xxx URLs (even
>> though the result is almost the same).  The reason is to do with the
>> order that locations are handled, specifically that ^~ locations are
>> handled before ~* and ~ ones, and if they match, then the regex ones
>> aren't tested.  If you try to access the URL /users/xxx, it will
>> therefore match the second location given by ^~, and return 404
>> because it's an internal location.  Therefore, trying access
>> anything under a user named 'users' will fail (though the URL /users
>> on its own is ok, because that will match the regex location and not
>> the ^~ location).
>>     
>
> It's somewhat obvious.
>   
To you, sure (and I'm sure to Piotr too) - I wrote the above more for 
anyone reading this who might not be as familiar with Nginx as you/Piotr 
are, since I felt the explanation wasn't obvious to everyone (just 
trying to be helpful, that's all).
>> Using location /users in the original locations will result in an
>> internal server error, because the regex will be caught before the
>> /users location each time the URL is checked, creating an infinite
>> loop.
>>     
>
> By "original" you mean config I'm suggested to Dennis J?  No, as 
> first rewrite will add '/' to it, and on next iteration it will be 
> caught by /users/.
>   
Sorry, my phrasing was bad.  I was referring your suggestion with the ^~ 
removed entirely (i.e. 'location /users' not 'location ^~ /users') - to 
highlight the difference between using ^~ and without anything (again 
not for your benefit).
>> I was under the impression that the way internal requests currently
>> work was a consciously-chosen decision, and was considered a
>> feature.  It's a useful one IMHO.  Surely if you want to make a
>> location fully 'invisible' (i.e. both internally and externally),
>> you can just add the directive 'return 404;' to the location.
>>     
>
> No, "invisible" != "one which returns 404".  The idea is 
> that internal locations should be ignored during matching of 
> external requests and let other (non-internal) locations match 
> request instead.
>   
Ah, I see.  Yes, that makes sense.

Marcus.