HSTS and TLS redirection: What is the correct order?

Question

Currently I am trying to setup my apache server for HSTS. Therefore my .htaccess looks like this:

<IfModule mod_headers.c>
    Header set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
    Header set Cache-Control "no-store, no-cache, must-revalidate"
</IfModule>

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

Now every request contains a "Strict-Transport-Security" header. But in some forums I have read that no HTTP request may contain an HSTS header. Therefore the order should be like this:

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

<IfModule mod_headers.c>
    Header set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
    Header set Cache-Control "no-store, no-cache, must-revalidate"
</IfModule>

But if I do this it seems like I can not add my site to the HSTS preload list on https://hstspreload.org/ because it says "no HSTS header present". So which one is correct?

Answer 1

At least historically, the HSTS Preload site required that HTTP requests must redirect to HTTPS before doing anything else. As such, the order given in your second block is correct. In particular, the redirect to HTTPS must occur before any other redirects (such as to a www. subdomain, or expanding a shortened URL to its full form).

Sending HSTS headers in non-HTTP requests is only an issue for non-compliant clients. A standards-compliant client will ignore all HSTS headers in insecure responses. With that said, the preload site absolutely should not expect the header in an HTTP response. Given that fact, I suspect that you've broken your HSTS header response somehow. Since you didn't give us the domain to test with ourselves, you should send requests to the domain in question - from the Internet side, not the local network or loopback address, in case you configuration differs between them - and verify that the Strict-Transport-Security header is present and correct on the HTTPS responses (use the browser dev tools, an intercepting proxy, or something like curl -v to check this).