Redirection problem again in new rules.

[Muhammad Yousuf Khan]

Thanks Alot Francis Daly, actually i was trying to understand the working
of rewrite and location rules how they handle the query. you explain it
very well. Thanks again for sharing such useful and detailed explanation. i
really appreciate that. :)



On Tue, Apr 19, 2016 at 4:23 AM, Francis Daly <francis at daoine.org> wrote:

> 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
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20160420/8e1fa6f5/attachment.html>