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