Forcing all requests to HTTPS vs not forcing all requests

Question

I'm not new to cleaning up mixed content errors after switching from http to https and I'm not new to working with the htaccess file but I am new to actually implementing the rules for http to https in the htaccess file. Obviously the goal is to switch all links that the search engines serve up from http to https but also to catch people who might have the site bookmarked at http or they happen to type in URLs manually because they have memorized them. I'm working with a WordPress site.

I read a lot of pages and thought I had a firm grasp on what to add to htaccess which was along the lines of...

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

I assumed (maybe incorrectly) that this handled all of my requirements (that being 1. Tell the search engines to switch, 2. Catch visitors with old bookmarks and 3. Catch people who type in a URL that they've memorized). I thought the above forced all requests.

Then I came across an article that seemed to suggest that people who type in a URL manually will not be redirected by just using the above condition/rule. The article said to force all requests with...

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE]

So now I'm confused. Do I use both of these together or do I just need the second one to ensure everything goes to HTTPS?

And speaking of working with WordPress I also came across another article that said WordPress can be set to force all requests to HTTPS in the wp-config with...

define('FORCE_SSL_ADMIN', true);

Is changing the wp-config needed if htaccess is being used or is it a good idea to have both (maybe wp-config acts as a failsafe)? I would like guidance on this from those better in the know.

Also.. if there is a better condition/rule to use than those noted above let me know.

Answer 1

I read a lot of pages and thought I had a firm grasp on what to add to htaccess which was along the lines of...

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

Exactly what directives you need to use can depend on your server configuration. And to some extent personal preference (eg. whether you check the HTTPS server variable or SERVER_PORT).

These directives (checking against the HTTPS server variable) are arguably the most common and should work when the SSL cert is installed directly on the application server (as opposed to a front-end proxy). This should be your goto HTTP to HTTPS redirect (but note the optimisation mentioned below^*1).

I assumed (maybe incorrectly) that this handled all of my requirements (that being 1. Tell the search engines to switch, 2. Catch visitors with old bookmarks and 3. Catch people who type in a URL that they've memorized). I thought the above forced all requests.

Yes, it would - providing they are the correct directives for your server config. The .htaccess file is processed for all HTTP requests and that includes 1, 2 and 3.

Then I came across an article that seemed to suggest that people who type in a URL manually will not be redirected by just using the above condition/rule.

Without seeing the article in question; that is incorrect. When a user "types a URL manually", it's an HTTP request just like any other.

The article said to force all requests with...

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE]

These directives should only be used if the HTTPS connection (SSL cert) is being handled by a front-end proxy. If not, then you will most certainly get a redirect loop. The condition above checks the X-Forwarded-Proto HTTP request header - which would ordinarily be set by a proxy server.

Likewise, if you used the first rule block that checks against the HTTPS server variable on a server that uses a front-end proxy to handle the secure connection then you would also likely get a redirect loop.

Always test with 302 (temporary) redirects if in any doubt.

Is changing the wp-config needed if htaccess is being used or is it a good idea to have both (maybe wp-config acts as a failsafe)?

Yes, you should also change the wp-config. At the very least, it is a failsafe. But also, you don't want the situation when you are redirecting to HTTPS and WP is redirecting back to HTTP. (I'm not actually sure whether that would happen, but it is certainly true the other way round.)

if there is a better condition/rule to use than those noted above let me know.

As noted above, any one way is not necessarily "better". Its what works for you.

^*1 However, there are small optimisations that can be made in the directive(s) you posted. For example, in your first rule, you use the less efficient regex ^(.*)$. This regex traverses the entire string and captures the entire match in a backreference. This is unnecessary in the context it is being used. You aren't using any backreferences in the substitution and you simply need to trigger the rule for anything. In which case, the regex used in the second rule, simply ^, is "better" as it's more efficient (net result is the same).

Note that the two RewriteRule directives are really "the same" - in what they actually do (they request the HTTPS version). It's just the preceding condition (RewriteCond directive) that varies.

Note also, that this is "only" an HTTP to HTTPS redirect. It doesn't, for example, canonicalise the www vs non-www subdomain. Some would argue that you should combine these two tasks into a single rule/redirect. Although that still isn't necessarily "better".