Welcome! Log In Create A New Profile

Advanced

Re: PHP below server root not served

Francis Daly
January 14, 2014 05:14PM
On Sun, Jan 12, 2014 at 09:27:23PM +1100, nano wrote:
> On 11/01/2014 2:34 AM, Francis Daly wrote:
> >>On 10/01/2014 8:36 PM, Francis Daly wrote:
> >>>>On 10/01/2014 7:58 AM, Francis Daly wrote:

Hi there,

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

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

I don't think I've ever looked for nginx regex documentation. I think
I've always just used "normal" regex characters, and they worked.

It's not difficult to test. Example below.

One thing that was not immediately obvious to me from the documentation,
was that the whitespace separating the uri from the modifier in the
location directive is optional. But it shows up pretty quickly in testing
(and is clear from the "real" documentation, which is in the directory
marked "src").

So: knowing that, it may make it easier to interpret other people's
config files.

> Also, what is the answer, I still cannot figure it out?

Which requests would match the original top-level prefix location?

Of those, which would match the first suggested nested regex location? And
which would match the second suggested nested regex location?

Are there any that would match only one of the two suggested nested
regex locations? If so, they don't match exactly the same requests.

> Thank you, Francis. I need to understand what each prefix and regex
> character is and what it does.

Fair enough. There are four modifiers (plus "no modifier"; plus @,
which is separate).

> For example, the documentation is clear
> that "^~" prefix will stop the search if it matches the request.

Yes, that's one of the four modifiers.

> However, there is nothing regarding "~^".

That's not one of the four modifiers. It is one of the four modifiers
followed by something else. There's also nothing explicit regarding
"~A". Or "~\.".

(If it doesn't start with one of the modifiers, then it is "no modifier",
which means "prefix string". If *that* doesn't start with /, it is
unlikely to be useful.)

Could """nginx: [emerg] invalid location modifier "~^" in
/usr/local/nginx/conf/nginx.conf:29""" be made clearer? The only way
you won't get that is if you don't have a separate uri in the directive.

> This might help me better
> construct my location blocks and ensure the correct location is used for
> each request.

"starts with ~" means "it's a regex". Everything after the ~ is the
regex. Apart from one documented case which could not be a regex anyway.

If you have as your server block the following:

===
server {
listen 8888;
location / { return 200 "location / \n"; }
location ~A { return 200 "location ~A \n"; }
location ~ \. { return 200 "location ~ \. \n"; }
location = / { return 200 "location = / \n"; }
}
===

Then can you predict the response to each of:

curl http://localhost:8888/path
curl http://localhost:8888/
curl http://localhost:8888/A.A

Add your sample locations, make your sample requests, understand why
each location was chosen each time.

Add

debug_connection 127.0.0.1;

to the "events{}" block if you want to see lots more in the error log.

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: 65
Record Number of Users: 6 on February 13, 2018
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready