On Fri, Mar 6, 2015 at 7:43 PM, Mike West <mkwst@google.com> wrote: > > > Unfortunately that does mean this mechanism is going to add a lot of >> bytes on the wire, and we should consider mitigations like shortening >> the Prefer: header, or only sending the Prefer: header for magic HTTPS >> URLs like favicon.ico (since it's just going to be there to refresh >> HSTS once every so often). > > > +Ilya and Yoav, who are poking at me about bytes on the wire in a separate > thread. I assume they have thoughts that are relevant here. :) > Thanks, Mike! :) Well, since at the Client-Hints effort we've heard similar concerns about sending even shorter headers on all navigation requests without an opt-in mechanism, I started wondering about the justification of the "Prefer" header here, and the benefits that over an opt-in only mechanism. What would be the consequences of the Upgrade mechanism only working as a way to get sites onto an "HSTS-lite" list, so that future navigations would be over HTTPS with their sub-resources upgraded, rather than blocked? What would be the lose in privacy/security here, vs. the benefits of not sending extra headers on each navigational request?
Received on Friday, 6 March 2015 19:34:04 UTC