Francis Daly
April 18, 2016 07:24PM
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@daoine.org

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Subject Author Posted

Redirection problem again in new rules.

Muhammad Yousuf Khan April 14, 2016 10:04AM

Re: Redirection problem again in new rules.

ph.gras April 14, 2016 11:20AM

Re: Redirection problem again in new rules.

Francis Daly April 14, 2016 01:06PM

Re: Redirection problem again in new rules.

Muhammad Yousuf Khan April 15, 2016 03:28AM

Re: Redirection problem again in new rules.

Francis Daly April 15, 2016 12:38PM

Re: Redirection problem again in new rules.

Muhammad Yousuf Khan April 16, 2016 03:24AM

Re: Redirection problem again in new rules.

Francis Daly April 16, 2016 08:38AM

Re: Redirection problem again in new rules.

Muhammad Yousuf Khan April 18, 2016 09:40AM

Re: Redirection problem again in new rules.

Francis Daly April 18, 2016 07:24PM

Re: Redirection problem again in new rules.

Muhammad Yousuf Khan April 20, 2016 06:36AM



Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 99
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 500 on July 15, 2024
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready