On Fri, Mar 6, 2015 at 8:16 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:
> On 6 March 2015 at 10:43, Mike West <mkwst@google.com> wrote:
> > I don't understand why HSTS needs to be conditionally set. Presumably
> you're
> > only redirecting "safely upgradable requests" to HTTPS if you're this
> spec's
> > target audience.
>
> I understood this as "If you support this upgrade, might as well just
> use HSTS". But can't save the extra bytes by disabling this signal if
> HSTS is enabled?
>
Yes. I think we're agreeing with each other.
I'm saying:
1. If the UA hits `http://example.com/`, it should send a signal: "Hey, I
support upgrades!". The server should interpret that signal as "Oh, great!
I'll redirect you to `https://example.com/?send-hsts=totally`, which would
respond with appropriate headers.
2. If the UA hits `https://example.com/`, it should not signal that it
supports upgrades. The server should respond with an HSTS header, because
HSTS is lovely.
I think Peter and Daniel (+dkg to join threads) are arguing that #2 is a
bad idea, because the server doesn't know whether the user accidentally hit
the HTTPS page or whether she was redirected there as part of an upgrade.
If that's a real concern for authors, then they have alternatives. For
example, we could add a DOM API. Or, perhaps more elegantly, the author can
tack on a request for `<img src="http://example.com/hsts-canary">` to the
document. If that gets upgraded, HSTSize the connection?
That's a very long way of saying that I think there are ways of doing this
that don't involve sending a header all the time forever. :)
-mike
--
Mike West <mkwst@google.com>, @mikewest
Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)