Re: HTTP 2.0 "Upgrade" flow

I don't understand why the initial HTTP/1.1 request from the client with 
the Upgrade header wouldn't also contain the client session frame as 
payload.

Or is this because the method may not permit a body?  If so, put it 
encoded into a request header.

Adrien


------ Original Message ------
From: "Ilya Grigorik" <ilya@igvita.com>
To: "Roberto Peon" <grmocg@gmail.com>
Cc: "Gabriel Montenegro" <Gabriel.Montenegro@microsoft.com>; "Ilari 
Liusvaara" <ilari.liusvaara@elisanet.fi>; "ietf-http-wg@w3.org Group" 
<ietf-http-wg@w3.org>
Sent: 17/04/2013 4:03:57 p.m.
Subject: Re: HTTP 2.0 "Upgrade" flow
>Thanks Gabriel. I think the workflow you outlined makes sense, but a 
>few wording clarifications..
>
>
>>>3.2 says:
>>>"The server sends the server session header immediately after 
>>>receiving and validating the client session header."
>>>
>>>That is not true if the server is the first one talking on the new 
>>>session (as in the Upgrade scenario). In this case, the server is the 
>>>first one, and it sends its 101, empty line, and then a SETTINGS 
>>>frame (aka as the server session header). In this case, the server 
>>>does not have the need nor the chance to validate the client session 
>>>header before sending its own.
>+1
>
>>>I think section 3.2 should be fixed as follows:
>>>OLD:
>>>After opening a TCP connection and performing either an HTTP/1.1 
>>>Upgrade or TLS handshake, the client sends the client session header. 
>>>The server replies with a server session header.
>>>
>>>NEW:
>>>After opening a TCP connection and performing either an HTTP/1.1 
>>>Upgrade or TLS handshake, the client sends the client session header.
>
>Is the client side of this even necessary in Upgrade case? Two 
>scenarios:
>
>a) client is only interested in a single request, but over HTTP 2.0
> > GET + Upgrade
>< 101 + SETTINGS + response frames
>
>There is no reason for client to respond with its own session header 
>here? It asked for 2.0, it got 2.0, if it got bogus bytes, it can 
>terminate the connection.
>
>b) let's assume (a) happens, but client now wants to send another 
>request in same session..
>
> > HEADERS
>< response frames
>
>Once again, there is no reason for client to append its session header 
>here? It asked for 2.0, it got 2.0, and its continuing to speak 2.0?
>
>>>OLD:
>>>The server sends the server session header immediately after 
>>>receiving and validating the client session header.
>>>
>>>NEW:
>>>The server sends the server session header (its SETTINGS frame) as 
>>>the first frame in the new session, per section 3.8.4.
>>>
>+1
>
>>>Section 2.2 could use some work as well:
>>>
>>>OLD:
>>>Once the server returns the 101 response, both the client and the 
>>>server send a session header (Section 3.2).
>>>
>>>NEW:
>>>Per section 3.8.4, the first of these HTTP/2.0 frames sent by the 
>>>server is its SETTINGS frame (which also constitutes the server 
>>>session header). Upon receiving the 101 response, the client sends 
>>>its session header (Section 3.2).
>
>As per comments above, not sure we need the second sentence? The client 
>session header is required for TLS case, and "naked" (clear text, no 
>Upgrade) case on port 80. I think..
>
>ig