- From: Cory Benfield <cory@lukasa.co.uk>
- Date: Thu, 27 Aug 2015 10:48:05 +0100
- To: Maxthon Chan <xcvista@me.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 27 August 2015 at 10:08, Maxthon Chan <xcvista@me.com> wrote: > Let’s say a software package, for example VMware vSphere, includes a HTTPS-only server, listening on port 5443. Usually to access the said software package you type this into the browser’s address bar: https://vsphere.example.org:5443/. What if you accidentally dropped the ‘s’ in ‘https’? It would be PITA to add the s between http and the colon if the user does not have a mouse, which is very, very common now. > > This is why among the two use cases of "Upgrade: STARTTLS” I suggested included not only a jump, but also in-place TLS handshake. The in-place handshake happens in the same TCP connection, immediately following the receiving of a response (with a 4xx status code) that contains this Upgrade: STARTTLS header. > > With in-place Upgrade: STARTTLS such scenarios can be avoided. > > Also, a Upgrade: STARTTLS of any type implies a Strict-Transport-Security. The server is clearly not HTTPS-only, because it can speak enough plaintext HTTP to send the 4XX back with the Upgrade header. Given that it can do that, it can clearly speak enough plaintext HTTP to send the 301 with Location header. As far as I can see the only advantage this extra header has is that it saves a TCP handshake.
Received on Thursday, 27 August 2015 09:48:37 UTC