Re: HTTP 2.0 "Upgrade" flow

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

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).
>>>
>>>
>>
>>