Re: HTTP 2.0 "Upgrade" flow

In your case a), it still simplifies the code to always send the same bytes
regardless of how/when the session is established.
The fact that an HTTP/2 response gets through a transparent proxy doesn't
necessarily mean that an HTTP/2 request will. For the reason above, plus
this, and given how cheap the session header is, it makes sense to simply
always send it.

There is a different potential argument here, though, which is: should the
server wait to respond until after it has received the client's session
header (as that stands the best chance of killing the connection when going
through an unhelpful transparent proxy)?
Doing so would make that connection fairly slow (latency wise), however...
-=R


On Tue, Apr 16, 2013 at 9:03 PM, Ilya Grigorik <ilya@igvita.com> wrote:

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