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 <fran...@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 fran...@daoine.org > > _______________________________________________ > nginx mailing list > nginx@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx >
_______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx