On 11/01/2014 2:34 AM, Francis Daly wrote:
> On Fri, Jan 10, 2014 at 10:37:50PM +1100, nano wrote:
>> On 10/01/2014 8:36 PM, Francis Daly wrote:
>>> On Fri, Jan 10, 2014 at 02:07:34PM +1100, nano wrote:
>>>> On 10/01/2014 7:58 AM, Francis Daly wrote:
>
> Hi there,
>
> This mail is going to sound a bit negative.
>

I find your disposition pleasant and more than generous, not negative at
all, Francis, and I am very grateful for your continued assistance.

>>>>> location ^~ /phpmyadmin/ {
>>>>> location ~ \.php$ {
>>>
>>> At this point, you could instead use "location ~
>>> ^/phpmyadmin/.*\.php$". It will match exactly the same requests --
>>> can you see why?
>>
>> Is it because "~^ /phpmyadmin/.*\.php$" will be the longest prefix
>> string
>
> No.
>
> "^~" is not the same as "~^". "~^ /" is not the same as "~ ^/".
>

Another presumption on my part, however, where is the nginx regex
documentation? I cannot seem to find it or even what syntax nginx uses.
Also, what is the answer, I still cannot figure it out?

> Read everything very slowly and carefully. The order of the various
> squiggles matters.
>
>>> Each nginx request is handled in one location.
>
>> But, doesn't "...the location
> <snip>
>> used" imply that all requests are subject to the entirety of the
>> configuration file and not just a specific location block?
>
> No. Read it again.
>
> What way of phrasing it would allow you to understand that one location
> is chosen? Perhaps a documentation patch could be provided.
>

I found the request processing page [0] more explicit and, for me,
comprehensible. A cursory look at any search engine result indicates a
lot of people struggle with this point; your suggestion of a
documentation patch might be a good idea. If I actually understood the
logic of this particular point well enough I would happily contribute to
the development of such documentation.

>> For example, if one specifies a location, such as /example/.*\.php$ and
>> assigns certain directives inside that location block, if there are
>> other matching expressions (\.php$) in the configuration file, they
>> could supersede any directives contained within the /example block
>> simply *because they come before the /example block?*
>
> No.
>
> One location is chosen.
>
> The configuration in any other location is irrelevant for this request.
>
> There is no superseding across locations. There is no merging across
> locations. There is only the configuration in, and inherited into,
> the one location that matters for this request.
>
>> It is good; repetition makes practice. And this point you reiterate is a
>> rule I am struggling to understand but that needs to be understood.
>
> After you accept that one location is chosen, then you can start wondering
> about what happens when there are nested locations, or when no locations
> match, and what happens when there are (e.g. rewrite module) directives
> outside of all locations.
>
> But until you accept that one location is chosen, you're unlikely to be
> comfortable making new nginx configurations.
>
> f
>

Thank you, Francis. I need to understand what each prefix and regex
character is and what it does. For example, the documentation is clear
that "^~" prefix will stop the search if it matches the request.
However, there is nothing regarding "~^". This might help me better
construct my location blocks and ensure the correct location is used for
each request.

[0] http://nginx.org/en/docs/http/request_processing.html

--
syn.bsdbox.co <- for dummies

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