nano
January 09, 2014 08:52AM
On 9/01/2014 11:57 PM, B.R. wrote:
> Try to understand what you are doing first.
>

I really am trying.

> One request is handled in one location.
>
> For this request, the one location that you want to be used is
> not the
> one that nginx actually uses.
>
> ​1. ​
> location / {
> ​2. ​
> location ~ \.php$ {
> ​3. ​
> location /phpmyadmin/ {
> ​4. ​
> location ~ ^/phpmyadmin/(.*\.php)$ {
>
>
>
> http://nginx.org/r/location
>
> A request for /phpmyadmin/index.php will be handled in the
> second location
> above, not the fourth.
>
>
> ​The docs say 'To find location matching a given request, nginx first
> checks locations defined using the prefix strings (prefix locations).
> Among them, 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.'
>

I did not (and still do not) understand it like you do. I had the
impression that each location block would adhere to its own assignments.
What defines a prefix string and a regular expression? Would " ~
^/phpmyadmin/(.*\.php)$ " not be the longest matching prefix to be
selected and remembered? And if so, despite it coming after the " ~
\.php$ " location, should it not be used?

> Thus, in your configuration, for a '/phpmyadmin/***.php' request, it
> does the following:
> * Start searching prefix location *
> 1. location /
> 3. location /phpmyadmin/
> * End of prefix location search, longest prefix = 3. *
>
> * Start searching regex expressions
> 2. location ~\.php$ // First regex found, stop of search
> * End of prefix location search, regex found is being used * //
> Otherwise, if no matching regex were to be found, a fallback to the
> longest prefix location found before would have applied
>

I think I am gradually understanding your explanation: despite location
3 being the longest prefix, regular expression in location 2 is found
and used. This found and used regex does not suit the requirements of
executing PHP instructions necessary to serve files from location 4? In
my example, nginx was instructing php-fpm to execute
/usr/local/www/site1/wordpress$fastcgi_script_name for phpMyAdmin files?

> Your problem is that the location 4. is *never* used, because the regex
> being used is the first which matches. Your generic '\.php$' will
> catch'em all!
> ​
>
> ​Francis provided 2 ways of fixing your problem:
> I. Re-arranging your config file so 'location /phpmyadmin/(.*\.php)$' is
> found /*before*/ \.php$​
>

I misunderstood Francis' advice. I thought he advised nesting my
/phpmyadmin location(s) inside the location ~ \.php$ block which further
broke my site.

> On Thu, Jan 9, 2014 at 1:41 PM, nano <nanotek@bsdbox.co
> <mailto:nanotek@bsdbox.co>> wrote:
>
> Admittedly, I don't know *why* what I changed fixed the problem, but
> it did. I relocated the phpMyAdmin entries to above the "location /"
> block from beneath the "location /" block.
>
> ​* snip *
>
> The syntax is identical, just those two location blocks are in a
> different place. I would like to know why this works, but am just
> happy that it does. I look forward to better understanding this
> great program.
>
> ​
> You did just that...
>
> II. Use a smarter (and more scalable, in light of future adds to the
> nginx config) way, which is nesting the rules of 'location
> /phpmyadmin/(.*\.php)$' in a 'location ~\.php$' block embedded in a
> 'location ^~ /phpmyadmin/' block.
>

Please, would you provide a working example of this for me to use? I
have been trying to create this smarter way but am failing miserably.
Does location ~\.php$ coming before /phpmyadmin/(.*\.php)$ (as it does
if the latter is nested in the former) not emulate the same situation I
created in the first place, thus rendering servername.com/phpmyadmin
broken? An example would help immensely and be very much appreciated. If
not mistaken, I understand you are suggesting the following structure
but, due to my failures in implementing such advice, it appears I need
something precise:

location / { }
location /phpmyadmin {
location ~\.php$
location /phpmyadmin/(.*\.php)$
}
}
}

> Note the modification made to the prefix block for phpmyadmin. The docs
> say 'If the longest matching prefix location has the “|^~|” modifier
> then regular expressions are not checked.'
> This way, longest prefix will be 'location /phpmyadmin/' /but the
> generic 'location \.php$' *won't be used*/ since there will be no regex
> search.
>

What exactly does this mean? Is this a proper assignment to avoid
phpMyAdmin scripts being affected by the generic php regex and *only*
using those assigned in the ~ ^/phpmyadmin/(.*\.php)$ location?

> Hope I helped,
>

I really appreciate your help. I am also very sorry that I do not have a
better understanding and lack the knowledge to fully benefit from your
assistance, but it is great you are helping. Thank you!


--
syn.bsdbox.co

_______________________________________________
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: 116
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