Remove www from the url

Hello everyone,

I used to use the following trick to cut the initial www. from the
address so that www.mysite.com would redirect to mysite.com:

server {
    server_name mysite.com www.mysite.com;

    if ($host ~* www\..*) {
        rewrite ^(.*)$ $1 permanent;
    }

Well, this method no longer works. I do not know when it stopped working
but I will get “The page isn’t redirecting properly” in Firefox. It
still puzzles me the documentation still implies this should work:

[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 or the first name of server_name directive, if
the header does not match or is absent. If no server_name is set, then
the local hostname is used. If you want Nginx to always use the “Host”
header, you can use a wildcard “*” server_name (but see the restrictions
on doing so)”[/quote]

Why is that and more importantly, what trick should I use to redirect
www.mysite.commysite.com?

Thank you!

Posted at Nginx Forum:

On Thu, Feb 17, 2011 at 9:44 PM, whiskybar [email protected] wrote:

Why is that and more importantly, what trick should I use to redirect
www.mysite.commysite.com?

If I remember correctly:

server {
server_name www.mysite.com;
rewrite ^ $schema://mysite.com$request_uri permanent;
}

On 2/17/11 9:44 AM, whiskybar wrote:

     rewrite ^(.*)$ $1 permanent;
 }

[/code]

Wrong way!

server {
server_name mysite.com;

}

server {
server_name www.myite.com;
rewrite ^ http://mysite.com$request_uri? permanent;
}

header, you can use a wildcard “*” server_name (but see the restrictions


nginx mailing list
[email protected]
nginx Info Page


Jim O.

On Thu, Feb 17, 2011 at 3:47 PM, Edho P Arief [email protected]
wrote:

If I remember correctly:

server {
server_name www.mysite.com;
rewrite ^ $schema://mysite.com$request_uri permanent;
}

Exactly what I was about to suggest. Seems to me like you do remember
correctly.

Regards,
Luit van Drongelen

edogawaconan Wrote:

If I remember correctly:

server {
server_name www.mysite.com;
rewrite ^ $schema://mysite.com$request_uri
permanent;
}

Good memory. Not “$schema” though, but “$scheme”

server {
  server_name www.mysite.com;
  rewrite ^ $scheme://mysite.com$request_uri permanent;
}
server {
  server_name mysite.com;
  ...
}

Posted at Nginx Forum:

Thank you all. Your solutions seem quite elegant.

Just a note, I was hoping for something I can do inside the server only
declaration, just like I can do with the opposite redirection mysite.com
www.mysite.com:

server {
    server_name www.mysite.com mysite.com;

    if ($host !~* www\..*) {
        rewrite ^(.*)$ http://www.$host$1 permanent;
    }

On the other hand, I feel your solution with the two server declaration
can even be a bit faster (not to mention easy to understand). Your
solution suggests I should rewrite the above code into two server
declarations as well.

Thank you very much!
Jiri

Posted at Nginx Forum:

On 2/17/11 10:03 AM, Dayo wrote:

Good memory. Not “$schema” though, but “$scheme”
[/code]
Not to be too pedantic, but unless you are using both http and https,
using $scheme is unnecessary. I only use it for such situations. Without
having read the code (not that I’d likely understand it anyway), and
Igor can comment on this, it would seem a waste.

Posted at Nginx Forum:
Re: remove www from the url


nginx mailing list
[email protected]
nginx Info Page


Jim O.

On 17.02.2011, at 18:08, whiskybar wrote:

server_name www.mysite.com mysite.com;
declarations as well.
Yes, two servers are easy to understand and faster, because
nginx does not run regex for main site:
Converting rewrite rules


Igor S.
http://sysoev.ru/en/

On Thu, Feb 17, 2011 at 09:44:10AM -0500, whiskybar wrote:

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,

f

Francis D. [email protected]

Hi Francis,

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.

Jiri

mysite.com matches the seconds word of server_name and that means it
matches the directive, you are right! Then, it

host part), then
exactly as Firefox does.

All the best,

f

Francis D. [email protected]


nginx mailing list
[email protected]
nginx Info Page

Posted at Nginx Forum:

On Thu, Feb 17, 2011 at 03:51:33PM +0000, Francis D. wrote:

Hi there,

But it looks to me as if the behaviour you see is to be expected, based
on the documentation you quote:

[from Module ngx_http_rewrite_module ]

“”"
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 or the first name of server_name directive, if
the header does not match or is absent. If no server_name is set, then
the local hostname is used. If you want Nginx to always use the “Host”
header, you can use a wildcard “*” server_name (but see the
restrictions
on doing so).
“”"

Other than a little bit of grammar, the documentation looks correct.

Actually, now that I look at it again and actually test, I believe
this documentation is wrong – at least as it relates to 0.9.4.

Reality seems to be more like

“”"
Note that if a redirect is relative (has no host part),
then Nginx generates the host part based on the value of
(./HttpCoreModule#server_name_in_redirect) server_name_in_redirect,
which now defaults to “off”.
“”"

That linked documentation says

“”"
If server_name_in_redirect is on, then Nginx will use the first value
of the server_name directive for redirects. If server_name_in_redirect
is off, then nginx will use the requested Host header.
“”"

which is true, but an extra note like “if the first value of the
server_name directive used is not a plain hostname, then generated
redirects are not likely to be useful” might warn people against blindly
setting server_name_in_redirect on.

Could someone with wiki access verify that and update the pages?

Cheers,

f

Francis D. [email protected]

server {
listen 80;
server_name test.co.uk;
rewrite ^ http://www.test.co.uk$request_uri permanent;
}

Posted at Nginx Forum:

Jim O. Wrote:

Not to be too pedantic, but unless you are using
both http and https,
using $scheme is unnecessary. I only use it for
such situations. Without
having read the code (not that I’d likely
understand it anyway), and
Igor can comment on this, it would seem a waste.
A bit too pedantic I think as you will note that the examples do not
include the “listen” directive … I.E. not sure if he is putting it
into the http or https sections so “$scheme” gives flexibility in
answering.

Posted at Nginx Forum: