Re: HTTP 2.0 "Upgrade" flow

I think that you either send the session header immediately after the
first request (the Upgrade) and risk having it swalled, or you send it
immediately before the next (HTTP/2.0) request.  In either case, you
don't incur an RTT delay.

If you thought that the server would wait for the client session
header before sending its SETTINGS, then I don't think that was every
the intention (the recent edits from Gabriel fix that problem, I
hope).  That would add an RTT and we don't want that.

On 17 April 2013 15:07, Adrien W. de Croy <adrien@qbik.com> wrote:
>
> my main concern is what does a forward proxy do.
>
> the client may choose to maintain a database of known http2 capable servers.
> This may be too much of a burden for the proxy.
>
> Discovery at the proxy could be a bit of a burden as well.
>
> A proxy offering 2.0 support to 2.0 clients but still having to talk to the
> great unwashed internet has quite a dilemma.  The safe/lazy/whatever option
> for the proxy may be to always use the Upgrade option.  Adding a RTT in this
> case will be seen by clients/customers as a performance degradation in many
> cases.
>
> Or maybe I've not thought this through properly.
>
>
> 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 10:00:47 a.m.
> Subject: 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:11:34 UTC