francis at daoine.org
Mon Feb 17 20:37:38 UTC 2014
On Mon, Feb 17, 2014 at 02:13:14PM +0100, B.R. wrote:
> What I called 'error handler' was the final argument of the try_files
> directive, the one used if any other one fails to detect a valid
So: the "uri" argument.
If try_files gets as far as the uri argument, there is an internal
redirection -- no files or directories are consulted at all.
(It can also be the "=code" argument, but that does not apply in this
> We ended concluding that:
> try_files $uri $uri/; was invalid, looping internally for an infinite
> amount of time
> try_files $uri $uri/ /; was valid
> I still don't get why the first case is invalid, with all the input you
> provided me with:
> The request URI was '/', so $uri = /, thus the first agument of try_files
> should match the root directory and process it further (finding the index
> file, etc.).
The first argument is a "file" argument, and is the string "$uri". That
string does not end in "/" (it ends in "i"), and so try_files
will look for a file. Expand variables in the argument, prepend
$document_root, and try_files checks to see is there a file called
/usr/local/nginx/html/. There is not, so it moves to the next argument.
In the first case above, the next argument is the final argument, and so
is the "uri" argument, and so try_files expands the variables in it and
does an internal redirection to this new request and everything starts
again. In this case, that's a loop.
In the second case above, the next argument is not the final argument,
and so is another "file" argument. It is the string "$uri/", which ends in
"/", so try_files will look for a directory. Expand, prepend, and see is
there a directory called /usr/local/nginx/html/. There is, and so this
request is processed in the current context using that directory. The
rest of the configuration says "serve from the filesystem", and "serve
index.html in the directory", so that's what happens.
> Considering all that, one could wonder why the 1st syntax is invalid.
> I hope I clarified my question... It seems simple from my point of view :o\
The best I can suggest is that when you read the documentation, only
read the words that are there.
Don't read the words that you want to be there, don't read the words
that would be there if they were put in a different order, and don't
assume that there are typographical errors and that clearly they meant
to write something else.
(There may well be typos there, in which case corrections are presumably
welcome. But on first reading, if there is a way of parsing the words that
does not require there to be an error, that's probably the one to expect.)
Francis Daly francis at daoine.org
More information about the nginx