Re: HTTP 2.0 "Upgrade" flow

So you intend to make client SETTINGS available to the server prior to
the server commencing transmission.  This is the essence of what
Gabriel intends with his known state proposal.  He is concerned by the
asymmetry of the exchange when Upgrade is involved (as opposed to the
TLS session startup).  You should talk to Gabriel.

On 17 April 2013 14:56, Adrien W. de Croy <adrien@qbik.com> wrote:
>
> I think it would need to go in as a header.  Maybe even as an attribute to
> the Upgrade?  Not sure if that supports such things.  E.g.
>
> GET /bob.txt HTTP/1.1
> Host: somewhere.co.nz
> Upgrade: HTTP/2.0 ; session=[......]
>
> so that the server can respond with the resource in any case.
>
> Adding a RTT to all HTTP 2.0 connections I thought had been decided was a
> non-starter.  Or compared to TLS setup phase + NPN maybe it's no worse.
>
>
> Adrien
>
>
> ------ Original Message ------
> From: "Martin Thomson" <martin.thomson@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>
> Sent: 18/04/2013 9:51:47 a.m.
> Subject: Re: HTTP 2.0 "Upgrade" flow
>>
>> 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 22:01:14 UTC