Redirecting everything to https://www.?

[Christophe]

Hello,

I really can't manage to redirect:

• http://domainname.tld and http://www.domainname.tld to https://www.domainname.tld
• https://domainname.tld to https://www.domainname.tld

I've searched on the Forums via Google, directly on Google... I can't find a working solution for the moment.

There is always something not working.

ERR_TOO_MANY_REDIRECTS, etc.

[Robin S]

These redirects can be made by uncommenting two portions of the PW .htaccess file:

• One
• Two

6 minutes ago, Christophe said:

ERR_TOO_MANY_REDIRECTS, etc.

If you're seeing this when trying to access the PW admin then it could be due to old browser cookies - try clearing the cookies for your domain.

[Mike Rockett]

5 hours ago, Robin S said:

If you're seeing this when trying to access the PW admin then it could be due to old browser cookies - try clearing the cookies for your domain.

Surely you mean cache?

[Robin S]

3 minutes ago, Mike Rockett said:

Surely you mean cache?

No, I mean cookies. I've experienced endless redirect issues when PW gets confused about my logged in status, perhaps due to the change of cookie name from "wire_challenge" to "wires_challenge" when accessing PW via the HTTPS protocol. Deleting the existing session cookies and logging in again solves the issue.

The browser cache has no impact on your logged in status.

[gurkendoktor]

Quote

The browser cache has no impact on your logged in status.

Chrome does cache redirects though for performance reasons. So if you put a 301 (Moved Permanently) in your config and mess it up, it will look wrong in Chrome even if you already corrected it. So you might want to clear the cache as well, just in case.

[Mike Rockett]

7 hours ago, Robin S said:

No, I mean cookies. I've experienced endless redirect issues when PW gets confused about my logged in status, perhaps due to the change of cookie name from "wire_challenge" to "wires_challenge" when accessing PW via the HTTPS protocol. Deleting the existing session cookies and logging in again solves the issue.

The browser cache has no impact on your logged in status.

I'm so sorry - wasn't thinking when I wrote that... My apologies. 

@gurkendoktor is correct though... I'm not sure how the system works with PW, but it should desregard old cookies, no?

[Christophe]

In Firefox, I also have:

The page isn’t redirecting properly

Firefox has detected that the server is redirecting the request for this address in a way that will never complete.

This problem can sometimes be caused by disabling or refusing to accept cookies.

I test and clear the cache in at least 3 browsers: chromium, firefox, and opera.

It's even when not logged in.

I've cleared the cookies this time (there was at least wire_challenge). I haven't seen wire_challenges in the cookies' list for the moment.

@Robin S Of course, I've already tried with One and Two, and many other things from the Internet.

I've tested with RewriteBase / activated also.

With One and Two enabled, I have:

the error message,

http://domainname.tld redirected to https://domainname.tld

http://www.domainname.tld redirected to https://www.domainname.tld

https://domainname.tld NOT redirected to https://www.domainname.tld

Let's Encrypt is activated by the hoster.

[rick]

@Christophe

I had too many redirects at one time in the past which was due to the same thing you are trying to accomplish.

With my registrar, the dns option to redirect using a wildcard, such as *.domain.tld (www.domain.tld) to domain.tld covers the initial redirect.

Then you can leave the htaccess file to change http to https.

This resolved the issue for me.

[Christophe]

@rick  It seems that I don't have any other solution than doing it at that level.

I've also posted a second message on the hoster's forum in case, as the first answer there wasn't helpful at all.

The domain name is hosted at another hoster, so I guess I have to ask it there, in my particular case.
I have kept the webmail with the registrar (gandi).

Let's Encrypt is activated at the website hosting.

Edited May 22, 2017 by Christophe

[rick]

I run let's encrypt too, without any errors, so I don't believe it is a problem with that addition.

So your domain is at a registrar and your hosting is with a different provider? Just look to your registrar for the dns change. It doesn't have anything to do with your hosting provider, other than getting the correct IP address.

[Mike Rockett]

I would say that each rule should force both scenarios:

# Force www and HTTPS
RewriteCond %{HTTP_HOST} !^$
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [R=302,L]

# AND force HTTPS and www
RewriteCond %{HTTPS} !on
RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [R=302,L]

Remember to change 302 to 301 when done testing.

[gurkendoktor]

Do you have a certificate for both https://example.com and https://www.example.com?

  RewriteCond %{HTTPS} off
  RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

might confuse 

 RewriteCond %{HTTP_HOST} !^www\. [NC]
 RewriteRule ^ http://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

The last line you should change into https://, as it would redirect it to the HTTP version which would then again being caught by the previous rule. Mind you: a redirect is always a new request, so the rules are being processed again. This can lead to confusion and "unforeseen behaviour" which is actually technically correct – just not what you intended. 

So what happens in the above rules is when you enter:
http://example.com => gets rewritten to https://example.com at the first rule, the next request is triggering the second rule (missing "www") and rewriting to http://www.example.com, which then gets caught by the first rule again. The next request should actually go through, maybe there is something here we don't see.

https://example.com => gets rewritten to http://www.example.com and caught by the first rule again upon next request.

http://www.example.com should be plainly rewritten to https://www.example.com without any problem, except there is something we don't see here.

https://www.example.com should be left untouched and give you the site immediately. The first two you should improve (this is a reason why Chrome caches these redirects, it's  always another TCP round trip and more load on your server).

Except there is something we don't see here.

Or just try Mike's version

[Christophe]

@Mike Rockett With your code, everything is redirected to https://www.www.domainname.tld

@gurkendoktor I have the certificate for both: I have the green lock for both on Chromium and Firefox.
I have already tried RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
And again now. Still the problem.

I'm not the only one wanting to redirect everything to https://www. and having this issue, am I?

@rick I'm waiting for an answer from the registrar.

It's the first time with this particular combination of registrar and website hoster.
(And sometimes it's the same one.)

[Mike Rockett]

1 hour ago, Christophe said:

@Mike Rockett With your code, everything is redirected to https://www.www.domainname.tld

Right - untested code, based on a theory trying to avoid two jumps. Wish servers made this easier.

[gurkendoktor]

Quote

Wish servers made this easier.

This is why I love nginx

 

[Christophe]

Solution, tested and given by the web hoster, which works.
I've just added it (without RewriteEngine On as it is already present) as one block between # 13. and # 14.

  RewriteEngine On
  RewriteCond %{HTTP:X-Forwarded-Proto} !https
  RewriteCond %{HTTPS} off
  # First rewrite to HTTPS:
  # Don't put www. here. If it is already there it will be included, if not
  # the subsequent rule will catch it.
  RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
  # Now, rewrite any request to the wrong domain to use www.
  # [NC] is a case-insensitive match
  RewriteCond %{HTTP_HOST} !^www\. [NC]
  RewriteRule .* https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

The web hoster couldn't understand at one point why it was not working.
They were Web4all, now they are Yulpa.

Something I've found today that could be (one of) the reason(s):

Quote

When writing new or importing existing rewrite rules for HTTP/HTTPS redirection on the ... platform, you also need to check for the presence and value of the HTTP:X-Forwarded-Proto header. As Apache runs on separate servers from your load balancers (where incoming requests are received), Apache does not know if a request was made over HTTP or HTTPS. Thus, when the balancers pass requests on to Apache, it sets the HTTP:X-Forwarded-Proto header to "http" or "https". Without checking for this header, HTTP/HTTPS redirect rules will not work as expected.

 

[Christophe]

Is someone already using a version with always one redirect only?

I don't mind if it's not generic and I have to specify the domain name.

PageSpeed Insights is not "happy"... not only with this last website.
Also, it seems, with the ones where I just uncommented Processwire's .htaccess rules.

Normally google will only index my preferred url. But in case people type it (or it is written) a certain way.

Something that just translates :

• if it starts with http://domainname.tld make it "redirect" to/start with https://www.domainname.tld 
• or if it starts with http://www.domainname.tld ... to https://www.domainname.tld
• or if it starts with https://domainname.tld ... to https://www.domainname.tld 

I don't know how/if using [OR] would work.

(And eventually the place(s) where it's best to put/keep it in the .htaccess file, for no conflicts, or for performance reasons.)

Thank you in advance!

[AndZyk]

Sorry, if I am not helpful, but I just want to add that I always used the following solution on different hosters and never had issues with Google:

On 22.5.2017 at 1:20 AM, Robin S said:

These redirects can be made by uncommenting two portions of the PW .htaccess file:

• One
• Two

Maybe your hoster had a different sever configuration, but this solution is the recommended one. 

[Christophe]

Hello @AndZyk,

PageSpeed Insights

1) For the website (Yulpa hoster) using the code at 

With (only) http://domainname.tld, I have:

Avoid landing page redirects

Your page has 2 redirects. Redirects introduce additional delays before the page can be loaded.

Avoid landing page redirects for the following chain of redirected URLs.

• http://domainname.tld/
• https://domainname.tld/
• https://www.domainname.tld/

2) For the website (OVH hoster) using the code from ProcessWire's .htaccess file (# 9 and # 13 uncommented)

a) For https://www.domainname.tld/, I have:

Avoid landing page redirects

Your page has 2 redirects. Redirects introduce additional delays before the page can be loaded.

Avoid landing page redirects for the following chain of redirected URLs.

• https://domainname.tld/
• http://www.domainname.tld/
• https://www.domainname.tld/

b) For http://domainname.tld/, I have:

Avoid landing page redirects

Your page has 3 redirects. Redirects introduce additional delays before the page can be loaded.

Avoid landing page redirects for the following chain of redirected URLs.

• http://domainname.tld/
• https://domainname.tld/
• http://www.domainname.tld/
• https://www.domainname.tld/

All this doesn't seem good to me...

[AndZyk]

Ah ok, I can see what you mean now.

I have tested one of my websites with Google PageSpeed Insights and when I test http://example.tld/, I also get this warning.

But I don't think it is really an issue, because if Google etc. have listed the right version of your website with https://www.example.tld/, those visitors wouldn't be redirected at all. You can always tell which is the right version via the search console.

Of course if there is a better solution for this case, I am interested. 

[rick]

Maybe I am missing something, which is quite possibly the case. So please educate me.

There are two protocols, http and https, for a single domain, but including the extraneous www, gives four combinations. As previously mentioned, www can be defined at the Address record level (or CNAME depending on provider) at your hosting provider. This in effect allows users to type or link to www.yourdomain.com and yourdomain.com resulting in the same hosting server doc root destination. So that leaves the two protocols remaining.

Are you serving content specific to a non secure site that is not available through the secure site? If there is no specific content unique to one site, then you can use https://yourdomain.com (better google results), and also set the ProcessWire templates to https only (Although that last part is optional).

In my non-secure site conf file, I redirect non-secure requests to the secure site by the following:

<VirtualHost x.x.x.x:80>
   ServerName domain.com
   Redirect permanent / https://domain.com/
</VirtualHost>

This is my exact setup, and using the ProcessWire generated htaccess file. Google's page speed reports, "In our test, your server responded in 0.28 seconds." There were no re-direct incidents, and visitors can access my secure site using any of the four combinations.

Like I said, if I am missing something, then please let me know. I'm always open to learning something new.

[Christophe]

@rick

Quote

then you can use https://yourdomain.com (better google results), and also set the ProcessWire templates to https only (Although that last part is optional).

Do you mean that, in general, there are better google results if the non-www version is used as the canonical version?
The 2 domain names are quite long, so perhaps this time I should choose the non-www version.
Also, I may have less problems/redirects.
But in that case, I'll have to (find how to) modify the code already used for both websites.

I'll eventually set the ProcessWire templates to https, as I don't have many of them.

Quote

 

In my non-secure site conf file, I redirect non-secure requests to the secure site by the following:

<VirtualHost x.x.x.x:80>
   ServerName domain.com
   Redirect permanent / https://domain.com/
</VirtualHost>

 

In which non-secure conf file? Edit: (Not) the ProcessWire generated .htaccess file?
I'm using shared hosting. Perhaps at least one is a "virtually"-shared installation. 

All protocols are pointing to the same website content.
For one of the websites, the domain name register and the website hoster are different.

Have a nice day/evening!

Edit 2: if only we didn't need to redirect anything (at least between www and non-www), but just had to mark one as canonical/main (tag, console...).

Edited May 31, 2017 by Christophe

[rick]

2 hours ago, Christophe said:

Do you mean that, in general, there are better google results if the non-www version is used as the canonical version?

I was referring to google moving toward the https preference; a secure site is preferable to it's non-secure counterpart. Also, the www prefix became redundant a few years back and isn't necessary any longer. The dns record accounts for those users who still use it.

2 hours ago, Christophe said:

But in that case, I'll have to (find how to) modify the code already used for both websites.

You have two separate web sites with two separate domains, or is this what you were referring to with www.domain.com pointing to one site, while domain.com points to the other?

2 hours ago, Christophe said:

In which non-secure conf file? Edit: (Not) the ProcessWire generated .htaccess file? I'm using shared hosting. Perhaps at least one is a "virtually"-shared installation.

Depending on your hosting provider, there are configuration files specific to a domain located somewhere. I run unbuntu on my laptop (LAMP) and debian (LAMP) on my production server. Apache is using sites-available/sites-enabled structure to hold the virtual config files. My non-secure (http) virtual config looks at requests on port 80 (non SSL) and redirects to https.

2 hours ago, Christophe said:

All protocols are pointing to the same website content.
For one of the websites, the domain name register and the website hoster are different.

This is where I was getting confused. You mention both protocols (http and https) point to the same content, but you also mention how to modify the code used for both sites. Is it two different sites serving the same content?

Having separate registrars and separate hosting providers is only a management issue for you (or whomever is responsible) by having to log in to different accounts to manage the information. Purely as an option, you could eventually consolidate your domains under one registrar, and even place all the domains on one hosting account.

[szabesz]

I'm not an .htaccess guru, but I dug up this one from the forum some time ago (sorry, I dunno where it was posted and by whom):

# inserted before the block "# 13. OPTIONAL: Redirect users to the 'www.' version of the site (uncomment to enable)."

# -----------------------------------------------------------------------------------------------
 # OPTIONAL: Redirect users to the non 'www.' version of the site (uncomment to enable).
 # For example: http://www.processwire.com/ would be redirected to http://processwire.com/
 # -----------------------------------------------------------------------------------------------

 RewriteCond %{HTTP_HOST} ^www\.
 RewriteCond %{HTTPS}s ^on(s)|off
 RewriteCond http%1://%{HTTP_HOST} ^(https?://)(www\.)?(.+)$
 RewriteRule ^ %1%3%{REQUEST_URI} [R=301,L]

This is for non www of course, but it works for me on cPanel shared hosting sites. I do not like www, so I never tried the opposite.

EDIT: I've found the source:

 

Edited June 1, 2017 by szabesz

[SiNNuT]

Just skimming this thread quickly but wanted to point to the html5 boilerplate htaccess which has some pretty robust stuff for supressing/forcing www and https. These have always worked for me on a variety of hosts. 

https://github.com/h5bp/server-configs-apache/blob/master/dist/.htaccess