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

This will cause a non-conformance server to freak out and start a reload. By allowing a server to announce its HTTP/2 availability a reconnect/reload can be avoided.

> On Apr 1, 2015, at 05:16, Matthew Kerwin <matthew@kerwin.net.au> wrote:
> 
> 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/ <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/ <http://matthew.kerwin.net.au/>