Add FAQ for hstspreload.org not detecting header when other sites do

[nharper]

Some websites will check what headers a website is serving and those reports sometimes conflict with what hstspreload.org says for a domain's Strict-Transport-Security header. Usually this conflict is because other scanning websites follow redirects while hstspreload.org looks at the headers on the response to the original request. (One such example of a scanning site is securityheaders.com, which defaults to following redirects.)

We should consider adding an FAQ section with an entry addressing this. (The Q could be something like "hstspreload.org says my domain isn't serving the Strict-Transport-Security header, but other tools see it. What's happening?")

[lgarron]

Sounds pretty sensible, if you're facing a lot of such questions.

Although this issue probably affects less technical users, I would also suggest generating a curl command that shows exactly the main request being tested against, e.g. curl -I "https://garron.net/". We could also add richer information to error messages to this end.

(We do have the hstspreload CLI that's easy to install if you have Go on your system, but I don't think that's going to be as intuitive: go install github.com/chromium/hstspreload/...@latest; hstspreload preloadabledomain garron.net)

[evazquez00]

So what about when the WebUI red flags that the HSTS header is missing, but the command line hstspreload returns an observed header and says "Satisfies Requirements" in bright green?

Is that a bug or a feature and how do we as end-users deal with the inconsistency?

[lgarron]

So what about when the WebUI red flags that the HSTS header is missing, but the command line hstspreload returns an observed header and says "Satisfies Requirements" in bright green?

Is that a bug or a feature and how do we as end-users deal with the inconsistency?

That should be pretty rare, but I'd suggest either naming the site here or emailing the contact email to either diagnose or manually preload the site.