Disable auth_basic for unique (set of) URL

[B.R.]

And... thanks again for all that information.
Greatly appreciated!

As I told you, I configured my browser (Firefox) to never store anything
(passwords, cache, cookies: basically anything) at the end of a browsing
session.
Basically closing the browser clears everything up.

Using cURL, I had some errors about an IPv6 address which I do not know.
I checked with traceroute that the domain name was correctly resolved to the
IPv4 address of my server, but the IPv6 was not mine. The traceroute didn't
end up with anything since my server drops ICMP traffic.
I basically tried 'curl -o file.out http://domain.name/thisfile.php',
nothing fancy.
Using the right domain name (and not any other or even IP) is important
since my Nginx configuration serves content based on the requested name.

Rather than losing time with cURL, I checked that a wrong configuration
doesn't serves 'thisfile.php' and that a wrong configuration does.
Changing behavior allows me to confirm I don't have cache.

Thanks agains for all the details about the different types of
'location'behavior.
I must have read something about that quite some time ago. It went totally
out of my mind since then.

Problem solved, configuration cleared and tweaked for better performance.
I can't thank you enough (that is starting to be too much :oP)

---
*B. R.*


On Sat, Dec 29, 2012 at 4:51 PM, Francis Daly <francis at daoine.org> wrote:

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