On Mar 16, 2015 08:29, "Anne van Kesteren" <annevk@annevk.nl> wrote: > On Mon, Mar 16, 2015 at 7:12 AM, Daniel Kahn Gillmor > <dkg@fifthhorseman.net> wrote: > > I think the semantics are likely to include some sense of "it's safe to > > send me HSTS" as well, not just "redirect me", unless we are willing to > > consider some flavor of the HSTS2 suggestion. > As I've mentioned in some other threads, I think the link to HSTS is aspirational. I believe that servers requiring this mechanism are going to be unwilling to lock themselves into HTTPS right away. I'd prefer to ship something that solves the problem we know we have, and build upon it to solve related problems once we have some implementation experience and feedback from developers. > Yeah, in light of WebSocket Prefer: hsts might make more sense. The goal of the signal is to inform servers that require `upgrade-insecure-requests` as a stepping stone that the mechanism totally works for this particular user. Ideally, the server would then redirect the user to a reasonable location, and send the upgrade directive. WebSocket requests made from _that_ page would be transparently upgraded client-side (per https://w3c.github.io/webappsec/specs/upgrade/#websockets-integration). Given that context, `Prefer: https` makes sense to me, and seems to cover the cases we care about. -mike
Received on Monday, 16 March 2015 08:23:03 UTC