<div dir="ltr">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. :)<br><br> <br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 19, 2016 at 4:23 AM, Francis Daly <span dir="ltr"><<a href="mailto:francis@daoine.org" target="_blank">francis@daoine.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Apr 18, 2016 at 06:37:59PM +0500, Muhammad Yousuf Khan wrote:<br>
<br>
Hi there,<br>
<br>
</span><span class="">> Thanks alot Francis Daly :). the try_file option worked for me and location<br>
> tip also worked but try_file seems more better approach.<br>
<br>
</span>I'm glad you got it working for you.<br>
<span class=""><br>
> Btw, can you please explain this paragraph. actually i am really sorry for<br>
> this newbie type question. actually i have been working as ssytem admin for<br>
> last 5 years. now my Firewall concepts of rules are collapsing with nginx<br>
> rules.<br>
<br>
</span>No worries - nginx config follows its own rules, which are generally consistent but not necessarily the same as any other program.<br>
<span class=""><br>
> >location /x { rewrite ^ /x.html redirect; }<br>
> >fails because "location /x" will match /x.html, so the second request<br>
> >will match the same location as the first one and the same redirect will<br>
> >happen again; and one way to avoid the loop is to make the "location"<br>
> >only match exactly "/x".<br>
> >Based on that, can you guess what the "~" in<br>
><br>
> can you please explain how the second request creates the loop. if i use<br>
> break instead of redirect?<br>
<br>
</span>I don't understand the question.<br>
<br>
What break, and what loop?<br>
<br>
I thought you had said that when you used "break" instead of "redirect"<br>
in the above "location /x", you got a 404. And that is what I would<br>
expect if the file $document_root/x.html does not exist. 404 is not a loop.<br>
<br>
Can you start with one specific configuration, and use the documentation<br>
(probably at <a href="http://nginx.org/r/rewrite" rel="noreferrer" target="_blank">http://nginx.org/r/rewrite</a>, since that seems to be the<br>
troublesome one) to work out what will happen?<br>
<br>
Note: when a request arrives, the server-level "rewrite"-module directives<br>
(basically: if and rewrite) are used; if that does not complete the<br>
request, then the location is chosen, and the "rewrite"-modules directives<br>
in that location are used.<br>
<br>
If a "rewrite" leads to an external redirect, that completes the<br>
request; and the browser may then come back with a whole new request<br>
that is handled afresh.<br>
<br>
If the "rewrite" leads to an internal rewrite (to a new url), then the<br>
"subrequest" of the new url is handled according to the docs -- possibly<br>
with a whole new selection of the location to use, depending on the<br>
arguments given to the rewrite.<br>
<br>
So: show your (simplified, but complete) config; show your http request;<br>
show your http response; and if appropriate, describe the response that<br>
you wanted to get instead.<br>
<br>
"break" does exactly what it says in the documentation. If that is<br>
unclear, let's fix the documentation.<br>
<div class="HOEnZb"><div class="h5"><br>
        f<br>
--<br>
Francis Daly        <a href="mailto:francis@daoine.org">francis@daoine.org</a><br>
<br>
_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx</a><br>
</div></div></blockquote></div><br></div>