it must have been for my bad understanding of "if the header match name
of server_name directive". I did not understand what "name of
server_name directive" was -- of course, mysite.com matches the
directive, you are right!
Then, it was the change of the server_name_in_redirect's default in
0.8.48 in addition to that - as you said. I'm running 0.9.x everywhere
and this is why it stopped working. I only did not notice.
That was a very clear explanation of you Francis, thank you. I'm
definitely not using this as everyone here suggested against it and I
will be using the two server solution.
mysite.com matches the seconds word of server_name and that means it
matches the directive, you are right! Then, it
> Hi there,
> By now you've seen the "approved" way to do what
> you want.
> But it looks to me as if the behaviour you see is
> to be expected, based
> on the documentation you quote:
> > "Note that if a redirect is relative (has no
> host part), then
> > when redirecting Nginx uses the "Host" header if
> the header match name
> > of server_name directive
> Host header is www.mysite.com. server_name
> includes www.mysite.com. So you
> rewrite http://www.mysite.com/abc to
> http://www.mysite.com/abc. It's quite
> reasonable for a browser to report that this isn't
> a useful redirect,
> exactly as Firefox does.
> Other than a little bit of grammar, the
> documentation looks correct.
> > Well, this method no longer works. I do not know
> when it stopped working
> Most likely it was in 0.8.48, where the default
> value for
> server_name_in_redirect was set to "off".
> That suggests that you could, if you wanted to
> avoid the
> "proper" way, keep your current configuration and
> add an explicit
> "server_name_in_redirect on".
> If you included mention of the previous and
> current versions used,
> it might show that that analysis is incorrect.
> All the best,
> Francis Daly firstname.lastname@example.org
> nginx mailing list
Posted at Nginx Forum: http://forum.nginx.org/read.php?2,176137,176186#msg-176186