Using HSTS with HTTP requests

At IndieWebCamp this last weekend, Ryan Barrett noted that he serves both secure and non-secure traffic on snarfed.org, and that instead of redirecting non-secure URLs to their secure equivalents, he sends an HSTS header for all content. That way, browsers that understand HSTS will eventually start switching over to the secure version of his site. I thought this was certainly a clever way to maintain support for older browsers that don’t support SNI (IE on Windows XP, mainly), but I mentioned that I was pretty sure that you weren’t supposed to do that. I couldn’t remember where I read that, and it turns out it’s right out of RFC 6797 (section 7.2 to be exact):

An HSTS Host MUST NOT include the STS header field in HTTP responses conveyed over non-secure transport.

And this makes sense. The whole point of the header is to indicate to clients that they should always use a secure transport. If that’s true, then you shouldn’t ever send any content over non-secure channels. There’s no real way to indicate that a secure option is available and is preferable, but not force clients to use it.