Disable auth_basic for unique (set of) URL

[Francis Daly]

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