- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Thu, 12 Feb 2015 14:29:11 +0100
- To: Mike West <mkwst@google.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, Peter Eckersley <pde@eff.org>, Eric Mill <eric@konklone.com>, Jacob S Hoffman-Andrews <jsha@eff.org>
* Mike West wrote: >While writing the example flow at >https://w3c.github.io/webappsec/specs/upgrade/#examples, I stumbled over >the problem of knowing when to redirect a user from an HTTP page to an >HTTPS one. If you require the upgrade mechanism we're defining in order to >give a user a reasonable experience, then you need to know whether or not >she's capable of performing the upgrade before redirection. > >I think we should explicitly support this sort of feature detection, rather >than relying on user agent sniffing*. Perhaps something like the following >HTTP request header could be sent along with every navigational request >(e.g. top-level navigations, new windows, and iframes): > > Accept-Upgrade: https > >Servers could inspect the headers of the request, and decide based upon the >presence of that header whether or not they were dealing with a client that >could transparently upgrade requests. If so, redirect to HTTPS if you're >not already there, if not, redirect to HTTP. That would redirect clients to the 'https' site even though they cannot connect to it for any number of reasons, for instance, the client might fail to negotiate TLS parameters with the server. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/
Received on Thursday, 12 February 2015 13:30:13 UTC