HTTP redirect without subdomain. about hstspreload.org HOT 8 CLOSED

May I ask why this needs to be the case?

This order makes sure that the client receives a dynamic HSTS header from example.com, not just www.example.com. Many, many sites have gotten this wrong since 2010 (the original post I want to cite is now private, but see here), and continue to do so.

There is another way to set HSTS on a parent domain, which is to include a token resource from the parent domain with HSTS. However, this requires more care, and has some non-obvious restrictions (e.g. I'm told Safari only records HSTS for sub-resources if they have a "first-party" relation like subdomain and parent domain).
http -> https -> https://www is is good enough to protect sites for the common use case (visiting links to the parent domain or typing them into the URL bar), and it is easy to understand and implement consistently. It's also simple for us and other folks to verify when scanning a site for HSTS.

This does impact the first page load, but will not affect subsequent visits.
And once a site is actually preloaded, there will still be exactly one redirect for users.

If I understand correctly, using HTTP/2 you can also reuse the https://example.com connection for https://www.example.com (if both domains are on the same cert, which is usually the case).

Given the growth of the preload list, I think it's reasonable to expect sites to use strong HSTS practices if they want to take up space in the Chrome binary. This requirement is the safe choice for most sites.

So I've setup a redirect, and from a performance point of view, I want to avoid doing two 301 redirects.

If you care strongly about performance, could you link directly to https://www.example.com?

from hstspreload.org.

This is wontfix for now, but I'm going to keep listening to feedback, especially if:

• there are significant considerations apart from a performance hit on the first visit, or
• someone has a suggestion that is equally safe, easy to implement correctly, and simple to check programmatically.

from hstspreload.org.

Any .htaccess files in your www directory, that prevent you from direct https forwarding?

from hstspreload.org.

Hi @henrocker, it's not a server setup thing, but how the HSTS Preload website want's it to work.

At the moment I do a redirect from:

http://example.com --> https://www.example.com

But the new validation rules want this to be:

http://example.com --> https://example.com
https://example.com --> https://www.example.com

Which is two 301 redirects, so an extra round trip (which, without HSTS coming into play, slows down the initial loading of the website).

from hstspreload.org.

Ahh, i get it @craigfrancis ,

thats indeed not the best way to preload hsts, Any work-arounds from others, or an official fix would be appreciated i guess!

from hstspreload.org.

Very good point, I wasn't thinking about how to ensure the browser would get the HSTS entry for the top level domain (on Thursday I was working on some performance updates, so my head wasn't in it).

So maybe the error message could be updated to explain this? either with a "details" link, where you are taken to a page explaining why, or maybe just change the wording a bit to say...

`http://example.com` (HTTP) should immediately redirect to
`https://example.com` (HTTPS) before adding the www subdomain. 
Right now, the first redirect is to `https://www.example.com/`. This extra
redirect is required to ensure that any browser that supports HSTS will record
the HSTS entry for the top level domain (and not just for the subdomain).

from hstspreload.org.

Only by chance, we discovered that this rule affected our site. The additional redirect is certainly not optimal but I can see the reasoning for it.

However, what worries me is that the requirements for the HSTS preload list can randomly change. Previously, our site was considered valid and then it suddenly showed this error message. Going forward, we may only notice months later that we are no longer on the preload list because of some new requirement.

I commented in issue #35 on this and hope you can add some notification when the requirements change.

from hstspreload.org.

However, what worries me is that the requirements for the HSTS preload list can randomly change.

The HSTS preload list is basically still an experiment, and the submission page doesn't include guarantees – only disclaimers. In order to do the best thing for Chrome users, we still need the right to change requirements.

However, this particular requirement is mainly intended to enforce a best practice going forward. We will not apply it to past domains without a carefully planned and announced pruning policy.

from hstspreload.org.