Redirect http to https htaccess code

[keyplyr]

What's the advantage of either method?

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

- or -

RewriteCond %{HTTPS} !=on
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]

[whitespace]

What's the advantage of either method?

Well, some "advantages" are really dependent on your situation.

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

ERROR: The pattern "(*)" is actually invalid here (this would obviously be a HUGE disadvantage! But I guess it's just a typo?), you probably meant "(.*)", but the parentheses are superfluous here, so ".*" or simply "^" would suffice - it just needs to match anything.

HTTP_HOST is the value of the Host header from the request. So, this could be "example.com", "www.example.com", "something.example.com" (wildcard subdomain) or even "another.com" (if you have multiple domains pointing to the same account). This could be an advantage if you want to redirect "http://<whatever>" to "https://<whatever>" (providing you have the appropriate SSL cert to cope) - but that could also be a disadvantage if you have a canonical host/domain (or a restrictive SSL cert). (Then again, you might be doing your domain canonicalization before this. But you could just as easily do it all in the one rule.)

R=301 - Any HTTP to HTTPS redirect should be a 301 - advantage.

Works in both the server config and per-directory .htaccess files - advantage.

RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]

Under a default config (ie. UseCanicalName Off) SERVER_NAME and HTTP_HOST actually refer to the same thing, ie. the Host as specified in the request. However, with "UseCanonical On" (if this is defined in the server config) then SERVER_NAME refers to the value of the ServerName directive (as defined in the main server config). So, this effectively canonicalises the redirect - an advantage (if that is what you want!). So, this could potentially redirect "www.example.com" to "example.com", without having to explicitly state the domain in the substitution.

Works in both the server config and per-directory .htaccess files - advantage (but the first rule satisfies this condition as well).

R - it's only a temporary (302) redirect. For an HTTP to HTTPS redirect this is unusual - a disadvantage.

[phranque]

What's the advantage of either method?

what problem are you trying to solve?

[keyplyr]

what problem are you trying to solve?

No problem, just getting ready to flip the switch from http to https. My host's set-up will allow both versions (after I turn on the cert) so want to force all requests to https.

Just one domain using www so you would suggest this?

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

- or -

RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

[not2easy]

I use one very similar to the regular canonical rewrite with the addition of https in place of http as in:

#Redirect invalid and non www requests
RewriteCond %{HTTP_HOST} !^(www\.example\.com)?$
RewriteRule (.*) https://www.example.com/$1 [R=301,L]

and a second one to convert third party resources to https (after determining whether they exist that way) to avoid the mild warning for mixed security. Not an ecommerce site and no logins needed.

RewriteCond %{SERVER_PORT} ^80$
RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]

[whitespace]

what problem are you trying to solve?

No problem, just getting ready to flip the switch....

I think it's worth pointing out, as with any mod_rewrite rule, that there isn't necessarily a perfect one rule for all.

Just one domain using www so you would suggest this?

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

- or -

RewriteCond %{HTTPS} !=on 
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

These two rules are functionally equivalent. However, in the first one the RewriteRule pattern is unnecessarily complex, so the second would be preferable. (That first one looks like a bit of a hybrid. You would use a pattern like that if you had a substitution string of the form ....//%{HTTP_HOST}/$1)

As mentioned above, the value of the HTTP_HOST server variable comes from the client. For this reason, many would argue that it's safer to hardcode the hostname in the directive (as in not2easy's post). This can depend on the server config and how the request is being canonicalised. Your call.

The non-www to www canonicalisation will also need to be updated to redirect to HTTPS. However, if you are doing this after the HTTP to HTTPS redirect above then this could result in 2 redirects, unless the hostname is hardcoded. ;)

[keyplyr]

My host's config pushes non-www to www... so would something as simple as this be all that is needed?

RewriteRule ^ https://www.example.com/$1 [R=301,L]

Also would existing in-site links (page to page) absolute links need to be changed to https or does the rewrite rule effectively do this?

[whitespace]

RewriteRule ^ https://www.example.com/$1 [R=301,L]

Not quite like that. Here $1 is always empty, so it will always redirect to the document root.

Something like what you had previously would be OK...

RewriteCond %{HTTPS} !=on 
RewriteRule ^ https://www.example.com%{REQUEST_URI} [L,R=301]

Also would existing in-site links (page to page) absolute links need to be changed to https or does the rewrite rule effectively do this?

Well, the user will get there, but they will be externally redirected (double the server hit), which is undesirable. (Although this will be pulled from the browser cache on subsequent clicks.)

Any absolute links should really be changed to HTTPS.

[keyplyr]

Thanks for the help :)