Re: HTTP 2.0 "Upgrade" flow

As proposed by Gabriel, SETTINGS (or equivalent) would/could be carried in
the headers in the UPGRADE request.
However, this isn't enough by itself-- you still want to cause transparent
proxies to barf when you start speaking HTTP/2 if they're not going to be
able to handle it.
-=R


On Tue, Apr 16, 2013 at 10:00 PM, Adrien W. de Croy <adrien@qbik.com> wrote:

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