On Wed, Jan 22, 2014 at 09:07:13PM +0000, Jonathan Matthews wrote:
> On 22 January 2014 20:36, Francis Daly <francis@daoine.org> wrote:
> > On Wed, Jan 22, 2014 at 02:54:35PM -0500, AD7six wrote:

Hi there,

> >> location ~ \.php$ {
> >> location ~* \.(?:manifest|appcache|html?|xml|json)$ {

> >> An invalid response when passed to php:
> >>
> >> $ curl -i http://nginx.dev/apples.json
> >> HTTP/1.1 404 Not Found
> >
> > Why do you think that this request is passed to php?
>
> I /believe/ AD is thinking along these lines:
>
> * I have a server{} level "try_files", which goes $uri, $uri/, /index.php?$args;

That is correct.

> * When file.json is present in the server{}-level root, it should be
> served (and is) due to try_files trying the "$uri" setting first;

That is incorrect.

Either check the debug log, or add something like

return 200 "location#2\n";

to the second location{} to get a better idea of what really happens.

> * When file.json is /missing/, the try_files setting should then
> result in nginx falling back to the php location,

That is incorrect.

Check the debug log; or make a request for /file.nomatch to see that
kind of behaviour.

> "You are probably under the delusion that try_files on server level
> must work for every request. Not at all. Quite the contrary, it works
> only for requests that match no location blocks."
>
> I'd be really interested to get confirmation that that statement is
> unequivocally true!

The true documentation is in the directory called "src". All else is
interpretations :-)

But if you don't want to accept someone else's word on it, the debug
log is usually reliable; and adding different "return" messages to each
location may help you figure out what nginx is doing.

(Especially when you realise that rewrite-module directives are special.)

f
--
Francis Daly francis@daoine.org

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx