Re: HTTP 2.0 "Upgrade" flow

["Adrien W. de Croy" <[e-mail]>]

Hi

------ Original Message ------
From: "Martin Thomson" <[e-mail]>
To: "Adrien W. de Croy" <[e-mail]>
Cc: "Gabriel Montenegro" <[e-mail]>; "Mark 
Nottingham" <[e-mail]>; "Ilari Liusvaara" 
<[e-mail]>; "Ilya Grigorik" <[e-mail]>; 
"[e-mail] Group" <[e-mail]>
Sent: 18/04/2013 10:11:06 a.m.
Subject: 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,
that could do nasty things if the server is only 1.1

>or you send it
>immediately before the next (HTTP/2.0) request. In either case, you
>don't incur an RTT delay.
next request may not exist.

Adrien
>
>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 <[e-mail]> 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" <[e-mail]>
>>  To: "Adrien W. de Croy" <[e-mail]>
>>  Cc: "Gabriel Montenegro" <[e-mail]>; "Mark
>>  Nottingham" <[e-mail]>; "Ilari Liusvaara"
>>  <[e-mail]>; "Ilya Grigorik" <[e-mail]>;
>>  "[e-mail] Group" <[e-mail]>
>>  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 <[e-mail]> 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" <[e-mail]>
>>>>   To: "Adrien W. de Croy" <[e-mail]>
>>>>   Cc: "Gabriel Montenegro" <[e-mail]>; "Mark
>>>>   Nottingham" <[e-mail]>; "Ilari Liusvaara"
>>>>   <[e-mail]>; "Ilya Grigorik" <[e-mail]>;
>>>>   "[e-mail] Group" <[e-mail]>
>>>>   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 <[e-mail]> 
>>>>>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" <[e-mail]>
>>>>>>    To: "Mark Nottingham" <[e-mail]>
>>>>>>    Cc: "Ilari Liusvaara" <[e-mail]>; "Ilya 
>>>>>>Grigorik"
>>>>>>    <[e-mail]>; "[e-mail] Group" 
>>>>>><[e-mail]>
>>>>>>    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).
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>