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.

_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx