Redirection problem again in new rules.

[Francis Daly]

On Mon, Apr 18, 2016 at 06:37:59PM +0500, Muhammad Yousuf Khan wrote:

Hi there,

> Thanks alot Francis Daly :). the try_file option worked for me and location
> tip also worked but try_file seems more better approach.

I'm glad you got it working for you.

> Btw, can you please explain this paragraph. actually i am really sorry for
> this newbie type question. actually i have been working as ssytem admin for
> last 5 years. now my Firewall concepts of rules are collapsing with nginx
> rules.

No worries - nginx config follows its own rules, which are generally consistent but not necessarily the same as any other program.

> >location /x { rewrite ^ /x.html redirect; }
> >fails because "location /x" will match /x.html, so the second request
> >will match the same location as the first one and the same redirect will
> >happen again; and one way to avoid the loop is to make the "location"
> >only match exactly "/x".
> >Based on that, can you guess what the "~" in
> 
> can you please explain how the second request creates the loop. if i use
> break instead of redirect?

I don't understand the question.

What break, and what loop?

I thought you had said that when you used "break" instead of "redirect"
in the above "location /x", you got a 404. And that is what I would
expect if the file $document_root/x.html does not exist. 404 is not a loop.

Can you start with one specific configuration, and use the documentation
(probably at http://nginx.org/r/rewrite, since that seems to be the
troublesome one) to work out what will happen?

Note: when a request arrives, the server-level "rewrite"-module directives
(basically: if and rewrite) are used; if that does not complete the
request, then the location is chosen, and the "rewrite"-modules directives
in that location are used.

If a "rewrite" leads to an external redirect, that completes the
request; and the browser may then come back with a whole new request
that is handled afresh.

If the "rewrite" leads to an internal rewrite (to a new url), then the 
"subrequest" of the new url is handled according to the docs -- possibly
with a whole new selection of the location to use, depending on the
arguments given to the rewrite.

So: show your (simplified, but complete) config; show your http request;
show your http response; and if appropriate, describe the response that
you wanted to get instead.

"break" does exactly what it says in the documentation. If that is
unclear, let's fix the documentation.

	f
-- 
Francis Daly        francis at daoine.org