RE: comprehensive TLS is not the solution, it's a bug ... (was 2 questions)

The fact that one major Internet company has a bad habit of returning 400 when they see Upgrade: Anything-other-than-WebSockets on a request.

But that’s a server bug, and we shouldn’t mandate protocol behavior to work around a single implementation’s bug – all the necessary pieces are already in HTTP/1.1.  You don’t need to abuse the Host header – the Upgrade header in a response is already defined to mean exactly that.  It’s a hint of protocols the server would be willing to upgrade to, if the client supports it.  A cautious client can wait for the server to advertise willingness to upgrade, then actually perform the upgrade on the next request.  (And presumably cache the fact for future savings of the RTT.)

From: phluid61@gmail.com [mailto:phluid61@gmail.com] On Behalf Of Matthew Kerwin
Sent: Tuesday, March 31, 2015 2:17 PM
To: Maxthon Chan
Cc: Walter H.; ietf-http-wg@w3.org
Subject: Re: comprehensive TLS is not the solution, it's a bug ... (was 2 questions)

On 1 April 2015 at 05:11, Maxthon Chan <xcvista@me.com<mailto:xcvista@me.com>> wrote:
Sorry for my not being aware of that as I am new to this list.
​
​

​
​

​The archives are at https://lists.w3.org/Archives/Public/ietf-http-wg/


A lot of ground has been covered there.​


​

​​
Any form of HTTP/1.1-based HTTP/2 protocol negotiation must allow a client to ignore hints of HTTP/2 availability and keep speaking HTTP/1.1.

How about this two-request protocol negotiation:

The first request is normal HTTP/1.1, and the server announces its HTTP/2 availability by including the string “HTTP/2” at the end of its Server header. This hint will be blissfully ignored by all older browsers that does not support HTTP/2, but it will be picked up by browsers supporting it.

The second request starts off with a HTTP/1.1 protocol upgrade to HTTP/2 and the server responds to the HTTP/1.1 protocol upgrade request with a HTTP/2 response, which will break non-HTTP/2 browsers (which is intentional here)

The browser can cache the HTTP/2 availability and all further communication, even a new session, can start with a HTTP/1.1 protocol upgrade and then full-blown HTTP/2 traffic.


​How is that any better than the client just sending Upgrade:h2c (or h2) with the first request?​


--
  Matthew Kerwin
  http://matthew.kerwin.net.au/