W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

Re: HTTP 2.0 "Upgrade" flow

From: Roberto Peon <grmocg@gmail.com>
Date: Tue, 16 Apr 2013 23:34:25 -0700
Message-ID: <CAP+FsNc7szKkwTz8Oz8xtDoYgWf-uyH0fpe59W5+Dd4Cj4CrQw@mail.gmail.com>
To: Willy Tarreau <w@1wt.eu>
Cc: "Adrien W. de Croy" <adrien@qbik.com>, Ilya Grigorik <ilya@igvita.com>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, Ilari Liusvaara <ilari.liusvaara@elisanet.fi>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Yup. The question there is only how we can do a reasonably effective
fast-fail with minimal effort.
-=R


On Tue, Apr 16, 2013 at 11:27 PM, Willy Tarreau <w@1wt.eu> wrote:

> Hi Roberto,
>
> On Tue, Apr 16, 2013 at 10:18:54PM -0700, Roberto Peon wrote:
> > As proposed by Gabriel, SETTINGS (or equivalent) would/could be carried
> in
> > the headers in the UPGRADE request.
> > However, this isn't enough by itself-- you still want to cause
> transparent
> > proxies to barf when you start speaking HTTP/2 if they're not going to be
> > able to handle it.
>
> However if the client knows from a previous connection that HTTP/2 is
> supported as an upgrade along the path, it can safely send its settings
> next to the headers, just as some browsers do with CONNECT requests sent to
> proxies. If a transparent proxy fails on this, it means it tried to parse
> the data following the headers as a new HTTP request, which means it's not
> compatible with the Upgrade mechanism anyway.
>
> Willy
>
>
Received on Wednesday, 17 April 2013 06:40:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:12 UTC