nano
January 10, 2014 06:40AM
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
Subject Author Posted

SSL ciphers, disable or not to disable RC4?

Anonymous User January 09, 2014 04:30AM

Re: SSL ciphers, disable or not to disable RC4?

nano January 09, 2014 04:44AM

Re: SSL ciphers, disable or not to disable RC4?

Jeffrey Walton January 09, 2014 04:54AM

RE: SSL ciphers, disable or not to disable RC4?

Lukas Tribus January 09, 2014 04:54AM

Re: SSL ciphers, disable or not to disable RC4?

Jeffrey Walton January 09, 2014 05:06AM

PHP below server root not served

nano January 09, 2014 05:26AM

Re: PHP below server root not served

Richard Stanway January 09, 2014 05:30AM

Re: PHP below server root not served

nano January 09, 2014 05:34AM

Re: PHP below server root not served

Francis Daly January 09, 2014 05:56AM

Re: PHP below server root not served

nano January 09, 2014 06:46AM

Re: PHP below server root not served

nano January 09, 2014 07:42AM

Re: PHP below server root not served

B.R. January 09, 2014 08:00AM

Re: PHP below server root not served

nano January 09, 2014 08:52AM

Re: PHP below server root not served

Francis Daly January 09, 2014 04:00PM

Re: PHP below server root not served

nano January 09, 2014 10:08PM

Re: PHP below server root not served

Francis Daly January 10, 2014 04:38AM

Re: PHP below server root not served

nano January 10, 2014 06:40AM

Re: PHP below server root not served

Francis Daly January 10, 2014 10:36AM

Re: PHP below server root not served

nano January 12, 2014 05:28AM

Re: PHP below server root not served

Francis Daly January 14, 2014 05:14PM

Re: PHP below server root not served

Valentin V. Bartenev January 15, 2014 02:20PM

Re: PHP below server root not served

nano January 10, 2014 04:38AM

Re: PHP below server root not served

nano January 09, 2014 09:44AM

Re: PHP below server root not served

Jim Ohlstein January 09, 2014 12:14PM

Re: PHP below server root not served

nano January 09, 2014 12:30PM

Re: SSL ciphers, disable or not to disable RC4?

Axel January 12, 2014 12:44PM

Re: SSL ciphers, disable or not to disable RC4?

Darren Pilgrim January 12, 2014 02:10PM

Re: SSL ciphers, disable or not to disable RC4?

Axel January 13, 2014 04:02AM



Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 139
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 500 on July 15, 2024
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready