Francis Daly
January 09, 2014 04:00PM
On Fri, Jan 10, 2014 at 12:51:24AM +1100, nano wrote:
> On 9/01/2014 11:57 PM, B.R. wrote:
> >On Thu, Jan 9, 2014 at 1:41 PM, nano <nanotek@bsdbox.co> wrote:

Hi there,

The nginx config follows its own logic, which may not match your previous
experiences. When you understand that, you'll have a much better chance
of knowing the configuration you are looking for.

One important feature is that one request is handled in one location.

Another is that there are very specific rules on how the one location
is selected. You are likely to find it frustrating to guess at possible
configurations, until you can determine for yourself which one location
will be used for a request.

The documentation for this is at
http://nginx.org/r/location, with a worked example at
http://nginx.org/en/docs/http/request_processing.html#simple_php_site_configuration
("How nginx processes a request" on http://nginx.org/en/docs/)

> 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.

I'm not sure what that means. nginx must choose which location block
to use. The config in, or inherited into, that block is the only config
that applies for this request.

> What defines a prefix string and a regular expression?

Documentation, paragraph 3, sentence 2. (Or see below.)

> Would " ~
> ^/phpmyadmin/(.*\.php)$ " not be the longest matching prefix to be
> selected and remembered?

No. If it starts "~", it's a regular expression.

> I think I am gradually understanding your explanation: despite location
> 3 being the longest prefix, regular expression in location 2 is found
> and used.

Yes, but I'd say "because" rather than "despite".

> This found and used regex does not suit the requirements of
> executing PHP instructions necessary to serve files from location 4?

I'm not sure what that means. The location chosen is the only one used
to handle this request. If the config isn't right, the config isn't right.

> In my example, nginx was instructing php-fpm to execute
> /usr/local/www/site1/wordpress$fastcgi_script_name for phpMyAdmin files?

....for any urls that matched the regular expression \.php$, yes.

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

What I intended was:

* option 1, preferred but more changes: regex location inside prefix
^~ location.

* option 2, fewer changes so quicker to do: swap the order of the two
regex locations.


> > 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.

Swapping the location blocks was enough to have the block you wanted,
be the one chosen for this request, because the first regex block that
matched was the one you wanted to be used. The other changes were then
presumably enough for the fastcgi server to know which file to process.

> >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.

I don't have a phpmyadmin install to hand here to test against, but will
be surprised to learn that there is no "here is how you install on nginx"
on the phpmyadmin site, or no "here is how you configure phpmyadmin" on
the nginx web site -- it doesn't seem like an especially unusual thing
to want to do, and hopefully someone who has done it has advertised what
they did.

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

No -- "nested" is different from "ordered".

When nginx chooses the one location to use for a request, it chooses
the one top-level location{} block to use. Within that block, if there
are further choices to make, they are independent.

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

The suggestion is along the lines of:

location ^~ /phpmyadmin/ {
location ~ \.php$ {
# config for php scripts to be fastcgi_pass'd elsewhere
}
# config for static files to be served directly
}

and then whatever other top-level location{} blocks that you want for
the rest of the server config -- possibly include a "location /" and a
"location ~ \.php$".


Overall, I find it helpful to think "what request am I making?", and
then "which location block will be used to handle it?". Followed by
"will that do what I want it to do?".

And have a small test system that you can easily change things on
and check.

Good luck with it,

f
--
Francis Daly francis@daoine.org

_______________________________________________
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: 161
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready