<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><font color="#333399"><font>And... thanks again for all that information.<br>Greatly appreciated<font>!</font><br><br></font></font></div><font color="#333399"><font>As I told you, I configured my browser (Firefox) to ne<font>ver store any<font>thing (passwords<font>, </font>cache<font>, </font>cookies: basically anything)</font></font> at the end of a browsing session.<br>


</font></font></div><font color="#333399"><font><font>Basically closing the <font>browser</font></font> clears everything up<font>.<br><br></font></font></font></div><font color="#333399"><font><font><font><font>Using cURL, I had some errors about an <font>IPv6 address <font>which I do no<font>t know<font>.<br>


</font></font></font></font></font></font></font></font></font></div><font color="#333399"><font><font><font><font><font><font><font><font><font>I checked with <font>traceroute <font>that the domain <font>name was<font> co<font>rrectly resolved to <font>the IP<font>v4 address of my server, but the IP<font>v6 was not mine. The traceroute didn't end up with anything since my server <font>drops <font>ICMP traffic.<br>


</font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></div><font color="#333399"><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font>I basically tried 'curl -o <font>file.out <a href="http://domain.name/thisfile.php" target="_blank">http://domain.name/thisfile.php</a>', nothing fancy.<br>


</font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></div><div><font color="#333399"><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font>Using the right domain nam<font>e (and not any other or even IP) is important since my Nginx configuration <font>serves content <font>based on the requested name.</font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font><br>


</div><div><font color="#333399"><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><br></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></div>


<font color="#333399"><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font>Rather than losing time with cU<font>RL</font></font>, I <font>checked that a wrong configuration doesn't serve<font>s 't<font>hisfile.php'</font></font></font> and that a wrong configuration does.<br>


</font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></div><font color="#333399"><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font>Changing behavior allows me to confirm I don't have cache.</font><br>


<br></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></div><font color="#333399"><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font>Thanks agains for all the details about the different types of 'location'</font> behavior.<br>


I must have read something about that quite some t<font>ime ago. It went totally out of my mind since then.<br><br></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></div>


<font color="#333399"><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font>Problem solved, configuration cleared and tweaked for <font>better performance.<br>


</font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></div><font color="#333399"><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font>I can't thank you enough (that is starting to be too much :oP)<br>


</font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font><div class="gmail_extra"><br clear="all">

<div><font size="1"><span style="color:rgb(102,102,102)">---<br></span><b><span style="color:rgb(102,102,102)">B. R.</span></b><span style="color:rgb(102,102,102)"></span></font></div>

<br><br><div class="gmail_quote">On Sat, Dec 29, 2012 at 4:51 PM, Francis Daly <span dir="ltr"><<a href="mailto:francis@daoine.org" target="_blank">francis@daoine.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div>On Sat, Dec 29, 2012 at 02:48:16PM -0500, B.R. wrote:<br>
<br>
Hi there,<br>
<br>
</div><div>> Thanks Francis for your insights. Your message has been a great help.<br>
<br>
</div>You're welcome.<br>
<div><br>
> Despite what you said, I don't have any cache configured yet (low-traffic<br>
> server) and the configuration I use requests authentification for all .php<br>
> file but the 'thisfile.php'. On the other hand, the browser I use doesn't<br>
> store any cache either.<br>
<br>
</div>I was unclear. The "cache" I mentioned was not intended to refer to the<br>
server at all.<br>
<br>
Browsers tend to cache things, including user/pass credentials previously<br>
provided. So "merely" hitting reload in a typical browser may auto-send<br>
credentials without showing you that that is happening.<br>
<br>
curl tends not to do that. If you don't include the credentials on the<br>
command line each time, you will get the 401 response each time.<br>
<br>
So curl is particularly good to test with when changing server<br>
configuration, as it starts from the same state each time.<br>
<div><br>
> I'd like more than theory on that particular point...<br>
<br>
</div><a href="http://nginx.org/r/location" target="_blank">http://nginx.org/r/location</a><br>
<br>
Given only "location /thisfile.php" and "location ~ \.php$", a request<br>
for "/thisfile.php" will match the second location, not the first.<br>
<br>
When I test using a configuration like that, I get the 401 response for<br>
all ".php" requests. I can't explain how your nginx acts differently.<br>
<div><br>
> I'm not a pro of cURL, never have been... I'm encountering some errors I am<br>
> having a hard time understanding.<br>
<br>
</div>I tend to test with, for example,<br>
<br>
  curl -i <a href="http://localhost/thisfile.php" target="_blank">http://localhost/thisfile.php</a><br>
<br>
"-i" shows the http response headers as well as the body; error states<br>
are usually shown in those headers.<br>
<br>
If the response to any request is not what you expect it to be, the error<br>
log and copy-paste'ing the request and response to the mailing list may<br>
help someone explain it.<br>
<div><br>
> What I didn't understand about the error is that placing a '~ \.php'<br>
> catch-all PHP reges inside 'location = /thisfile.php' isn't allowed but is<br>
> allowed inside 'location /thisfile.php'... Which is not more generic than<br>
> the previous one.<br>
<br>
</div>"location /thisfile.php" is a prefix match. A request for<br>
/thisfile.phpsome/thing can match this location. So nesting a location<br>
within it can be useful.<br>
<br>
"location = /thisfile.php" is an exact match (of uri, not considering<br>
query string). Only one request can match this location. Nesting another<br>
location within it is not useful -- it would either always match or never<br>
match, and the person writing the config can determine which it would<br>
be and either include or exclude the extra configuration unconditionally.<br>
<div><br>
> Tell me how many PHP files will match each one of the 'location' clauses.<br>
> I was excepting the same behavior regarding both those locations, either<br>
> both generating an error or both silent... Which is not the case.<br>
<br>
</div><a href="http://nginx.org/r/location" target="_blank">http://nginx.org/r/location</a><br>
<br>
Some locations can be nested, some can't.<br>
<br>
And the example there hopefully allows you to determine which location<br>
will be used for each request.<br>
<br>
Assuming exactly these two top-level locations, your prefix match<br>
"/thisfile.php" location will be used for all requests that start<br>
"/thisfile.php" and do not end in ".php" (where "end" means "just before<br>
the first # or ?"). Because of that, your nested "~ \.php$" location<br>
will not match any request.<br>
<br>
Your top-level "~ \.php$" will match all requests that end ".php".<br>
<br>
Whether those requests correspond to php files is a separate matter.<br>
<div><div><br>
        f<br>
--<br>
Francis Daly        <a href="mailto:francis@daoine.org" target="_blank">francis@daoine.org</a><br>
<br>
_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org" target="_blank">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx</a><br>
</div></div></blockquote></div><br></div></div>