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:
>
> Per nginx logic, location 4 is used for every request for which it is the
> "best match". It just happens that there are no such requests. It's the
> administrator's job to spot this "brokenness".
>

Hopefully I can improve my ability to identify and correct mistakes.

>> I still find this confusing: why has this move not broken the generic
>> location ~\.php$ block, which now comes after the location
>> /phpmyadmin/(.*\.php)$ block, rendering root requests (sitename.com)
>> broken?
>>
>> [...]
>>
>> How will having ~\.php$ nested inside ^~ /phpmyadmin affect the main site
>> (server root / sitename.com) WordPress administration of PHP? (I think
>> you may have already answered this with your upcoming example.)
>
> The same questions apply:
>
> What request do you make?
>
> What (top-level) location{}s do you have?
>
> Which one location will be chosen for the request?
>

I will contemplate these questions and try to find the right answers.

>>> The suggestion is along the lines of:
>>>
>>> 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 *and* will be selected because even though nginx would find
regular expressions in the configuration file that match the URI
request, the "^~" modifier instructs nginx to not search the regular
expressions?[0]

> Depending on the rest of your setup, there may be a reason to use this.

I am not sure if the rest of my setup provides reason to not implement
this improved location block: ~^ /phpmyadmin/.*\.php$
The deployments are simply WordPress + phpMyAdmin + ownCloud + Roundcube
with the last two on subdomain vhosts.

>> So, PHP directives, such as fastcgi_param SCRIPT_FILENAME, contained
>> within the ~ \.php$ location nested inside the ^~ /phpmyadmin/ location
>> will not apply to the rest of the site -- only to /phpmyadmin? The
>> subsequent location ~ \.php$ applies to the rest of the site?
>
> Each http request is independent.
>
> Each nginx request is handled in one location.
>

But, doesn't "...the location with the longest matching prefix is
selected and remembered. *Then regular expressions are checked, in the
order of their appearance in the configuration file. The search of
regular expressions terminates on the first match, and the corresponding
configuration is used.* If no match with a regular expression is found
then the configuration of the prefix location remembered earlier is
used" imply that all requests are subject to the entirety of the
configuration file and not just a specific location block?

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?*

> For each request, only the configuration in, or inherited into, the one
> location, applies.
>
> This may seem repetitive; that's because it is. Until you understand
> that point, you will not understand nginx configuration.
>

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.
Thanks again, Francis. Your input is very helpful. Much obliged.

[0] http://nginx.org/en/docs/http/ngx_http_core_module.html#location:
"If the longest matching prefix location has the “^~” modifier then
regular expressions are not checked."

--
syn.bsdbox.co <- for dummies

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