W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2015

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

From: Matthew Kerwin <matthew@kerwin.net.au>
Date: Wed, 1 Apr 2015 07:16:33 +1000
Message-ID: <CACweHNAqEkbgcOgtiq_V7oqWK6aQ6Fsb9VF++qZF0BAfo9vZbA@mail.gmail.com>
To: Maxthon Chan <xcvista@me.com>
Cc: "Walter H." <Walter.H@mathemainzel.info>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 1 April 2015 at 05:11, Maxthon Chan <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/
Received on Tuesday, 31 March 2015 21:17:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:43 UTC