3

My Goal: My goal is for new users who have never visited my page, and who are unlikely to explicitly type https:// in front of my-domain.com to land on the https://my-domain.com with a response code of 200 instead of landing on the http://my-domain.com first, and then be 301 redirected to the https://my-domain.com version, which is also cached.

My situation: I am undergoing an attempt to optimize all the WordPress sites I am the manager of. Many of those have the Really Simple SSL plugin installed and activated, mostly for addressing mixed content issues. I decided to uninstall the plugin on two of them, after reading an article (link) on potential performance decreases caused by it, which I wanted to put to the test. Apart from fixing mixed content, this plugin is also responsible for introducing a PHP or .htaccess 301 redirection. Since I was on Apache, and now LSWS, I had the .htaccess one enabled.

What I've tried so far: I started by deactivating the plugin, and temporarily reverting to http to erase all of the plugin's marks. I then deleted the plugin completely from the installation. That resulted in the home_URL and site_URL conversion to http, which I manually edited to https once again. Then ran a DB search/replace for every http:// instance to become an https:// one

Next I had the cPanel checked under Domains, where I enabled the Force HTTPS option there, and had the SSL status checked to verify there were no issues there (everything was green). I checked the .htaccess file to exclude the presence of any 301 remnants, and had the cache purged just in case. I did all of the above for both installations individually.

After all of that I visited URL my-domain-1.com and my-domain-2.com from a new chrome incognito session. I noticed that my-domain-1.com loads under https:// with a 200 response code, while my-domain-2.com still loads under http:// at first, and is then being redirected to https://, which has left me confused.

What should I have done differently, or what is it that I have been missing?

1 Answer 1

3

When a user types in a website URL without explicitly typing https, most web browsers will initially attempt to connect over http (though as Patrick mentioned, this is beginning to change - see Chrome and Firefox).

Currently, the only way to communicate to web browsers to never attempt to load your website over http, even the very first time they ever load your site, is to submit your domain for HSTS preload list inclusion.[1] The HSTS preload list is a list of websites that gets hard-coded into Chrome, Firefox, Safari, Edge, etc. that tells the browsers not to load your website over http, even when the browser is freshly downloaded and knows nothing else about your website at all.

I am not sure HSTS preloading is strictly necessary or offers much benefit in your setup (it won't offer any performance benefit after the initial connection compared to non-preloaded HSTS, since HSTS gets cached whether or not it is preloaded), but it is the only answer to your very specific question as asked. In other words, HSTS preloading is the only way to force https for first-time visitors who type your domain into their address bar without explicitly typing the https, aside from issuing a redirect over an initial http connection.

[1] Some entire TLDs are already on the HSTS preload list, such as .dev, but if your website's TLD were on that list, then you wouldn't be seeing this issue with it.

7
  • 1
    "When a user types in a website URL without explicitly typing https, most web browsers will initially attempt to connect over http." This is less and less true and will be reversed in the future. See blog.chromium.org/2021/03/… "Starting in version 90, Chrome’s address bar will use https:// by default," and blog.mozilla.org/security/2020/11/17/… (for now has to be setup as a preference) Commented Dec 8, 2021 at 18:34
  • 2
    "The only way to communicate to web browsers to never attempt to load your website over https" There is another very easy way: don't listen on port 80 (used for HTTP). Any new website starting now should just stop bothering with HTTP and just use HTTPS (port 443). Even if some browsers attempt port 80 they won't get any result hence ensuring nothing is leaked. Commented Dec 8, 2021 at 18:35
  • @PatrickMevzek Thanks for the info. I added a note about the new browser behavior. What do you mean by "ensuring nothing is leaked?" Commented Dec 8, 2021 at 20:47
  • 1
    There could be multiple answers to this, but it is akin to IPv4/IPv6. Things changed. If the web was invented today, it would be HTTPS immediately, no one would ever bother to consider a. "plain text" version of it. So since HTTPS is the clear present/future, why keep maintaining old stuff? Doing redirects might be fine but you need to remember doing them, they create problems for POST content (imagine a form), etc. If you start a website fresh, give only https:// links around and search engines will also only index that + browsers will default/are already defaulting to that. Commented Dec 9, 2021 at 0:45
  • 1
    But redirects "work" for those absolutely wanting to keep port 80 open for connections, so YMMV. Of course for a real website existing already today it might not be wise to plug off HTTP, but for anything new starting fresh I personnally see no point in having HTTP still around. Sadely not the same can be said yet for IPv6 vs IPv4, even if it should. Commented Dec 9, 2021 at 0:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.