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

Re: HTTP 2.0 "Upgrade" flow

From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 17 Apr 2013 14:51:47 -0700
Message-ID: <CABkgnnVq27RCHs=hCQTr97urQc54pHdMPKQ6+WXwHYxdA_tnkA@mail.gmail.com>
To: "Adrien W. de Croy" <adrien@qbik.com>
Cc: Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, Mark Nottingham <mnot@mnot.net>, Ilari Liusvaara <ilari.liusvaara@elisanet.fi>, Ilya Grigorik <ilya@igvita.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
It's possible that the client could pipeline the session header, but
that does stand a chance of being subsumed into the initial request.
I expect packet-based hacks.

On 17 April 2013 14:42, Adrien W. de Croy <adrien@qbik.com> wrote:
> My understanding was that we would not be sacrificing the first request due
> to a requirement to upgrade.
> In order for the server to send an actual response, if it needs the client
> session header, this should be sent in the initial request which includes
> the upgrade.
> Otherwise we just added a RTT
> Adrien
> ------ Original Message ------
> From: "Gabriel Montenegro" <Gabriel.Montenegro@microsoft.com>
> To: "Mark Nottingham" <mnot@mnot.net>
> Cc: "Ilari Liusvaara" <ilari.liusvaara@elisanet.fi>; "Ilya Grigorik"
> <ilya@igvita.com>; "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
> Sent: 18/04/2013 5:02:01 a.m.
> Subject: RE: HTTP 2.0 "Upgrade" flow
>>>  Personally, I'm not thrilled with how the server session header is
>>> conflated
>>>  with a SETTINGS frame... if we're going to require that the server send
>>> a
>>>  SETTINGS frame first (which is fine), let's just come out and say that,
>>> rather
>>>  than making it a side effect of requiring a (largely fictional) server
>>> session
>>>  header.
>> The spec already says that in section 3.8.4 that a SETTINGS frame MUST be
>> the first frame sent by either party in a new session.
>> So that part is fine. If we wish to say that a server has no session
>> header, that would be fine.
>> As for " As proposed by Gabriel, SETTINGS (or equivalent) would/could be
>> carried in the headers in the UPGRADE request."
>> For the record, I did not say that in the Upgrade scenario the client
>> session header is sent in HTTP/1.1 along with the Upgrade request. My
>> understanding is that the Upgrade request goes without the client session
>> header. As we have discussed in Orlando, we could add some HTTP/1.1 headers
>> to address the known state by conveying *some* of the settings (only those
>> absolutely necessary to achieve known initial state). But that's a separate
>> proposal/discussion from this thread.
>> At any rate, the server sends back the 101, and begins its HTTP/2.0
>> traffic by sending its SETTINGS frame and its response frames, and the
>> client upon receiving the 101, and only then, begins sending HTTP/2.0
>> traffic starting with its client session header (which includes the magic
>> sequence and the client SETTINGS frame).
Received on Wednesday, 17 April 2013 21:52:14 UTC

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