On Wed, Jun 24, 2015 at 05:19:52PM -0700, E.B. wrote:
Could you explain?
Sure I wanted to take a prefix:
and make sure all uris that match
that prefix are served to the same
For this mail thread, that’s probably fine. But for a general solution,
you’ll want to make sure that you are clear about what “served to the
same file” means.
If it is “serve a file from filesystem”, then alias and/or try_files may
be useful. If it is “send to an upstream such as via fastcgi_pass”,
then alias may not be needed at all.
this is interesting to me.
Generally, if I can avoid rewrite but achieve the same result simply,
that’s what I’d tend to do.
But without knowing what the original rewrite was doing, it was hard to
“alias” is, as you noted, documented at http://nginx.org/r/alias. It is
used to identify a filename that should be used to handle the request.
Im still wondering why the critical part
you kindly explaining below is not documented.
Isn’t this basic feature and important info
My suspicion is that what is documented is clear enough to the writer;
and no reader had previously pointed out any problems.
(I think that my explanation does follow from the documented words;
but I can see how it may not be immediately obvious. So if the
nginx documentation team is reading: this thread has some suggested
alternate/additional words for the documentation of “alias”.)
i discovered in the fastcgi conf file there
try_files $uri =404
so it overrided the alias and causeding
Yes; “alias” and “try_files” may not work together as you may
It doesn’t actually override the alias; but it does do (and fail)
a test that you probably do not want it to do.
(And that try_files line is part of “the configuration that is not yet
shown”. The “include” file could have almost anything in it which would
change the way that the configuration is understood.)
i guess this was a security
measure to prevent sneaking around the
filesystem for php requests.
I confess I’ve never been quite sure of the point of that line.
I can see what it does, and I think that it might be useful in some
limited circumstances which include “…and my php is configured badly
and I won’t change it…”; but I’ve tried to avoid those circumstances.
is there a
better way to effect same protection?
If you can specify what you consider the “same protection” to be,
And kudos for correct use of the verb “to effect”
try_files $request_filename =404???
That won’t do what you want because of how try_files handles its
Possibly in this one specific case – so not in fastcgi.conf that is
included elsewhere –
try_files “” =404;
would do it. But you know that you are sending SCRIPT_FILENAME (or
whatever your fastcgi server honours) set to one specific filename only,
and you know that the matching file exists. So what is the test doing
that would be bad if it were not done?
Francis D. [email protected]