On 11/01/2014 2:34 AM, Francis Daly wrote:
On Fri, Jan 10, 2014 at 10:37:50PM +1100, nano wrote:
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:
Hi there,
This mail is going to sound a bit negative.
I find your disposition pleasant and more than generous, not negative at
all, Francis, and I am very grateful for your continued assistance.
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
No.
"^~" is not the same as "~^". "~^ /" is not the same as "~ ^/".
Another presumption on my part, however, where is the nginx regex
documentation? I cannot seem to find it or even what syntax nginx uses.
Also, what is the answer, I still cannot figure it out?
Read everything very slowly and carefully. The order of the various
squiggles matters.
Each nginx request is handled in one location.
But, doesn't "...the location
<snip>
used" imply that all requests are subject to the entirety of the
configuration file and not just a specific location block?
No. Read it again.
What way of phrasing it would allow you to understand that one location
is chosen? Perhaps a documentation patch could be provided.
I found the request processing page [0] more explicit and, for me,
comprehensible. A cursory look at any search engine result indicates a
lot of people struggle with this point; your suggestion of a
documentation patch might be a good idea. If I actually understood the
logic of this particular point well enough I would happily contribute to
the development of such documentation.
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?*
No.
One location is chosen.
The configuration in any other location is irrelevant for this request.
There is no superseding across locations. There is no merging across
locations. There is only the configuration in, and inherited into,
the one location that matters for this request.
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.
After you accept that one location is chosen, then you can start wondering
about what happens when there are nested locations, or when no locations
match, and what happens when there are (e.g. rewrite module) directives
outside of all locations.
But until you accept that one location is chosen, you're unlikely to be
comfortable making new nginx configurations.
f
Thank you, Francis. I need to understand what each prefix and regex
character is and what it does. For example, the documentation is clear
that "^~" prefix will stop the search if it matches the request.
However, there is nothing regarding "~^". This might help me better
construct my location blocks and ensure the correct location is used for
each request.
[0] http://nginx.org/en/docs/http/request_processing.html
--
syn.bsdbox.co <- for dummies
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
