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.

YMMV.

 
On 17/04/2013, at 11:10 AM, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com> wrote:

>>> If the client "knows" that the server is HTTP 2.0 capable (DNS, previous
>>> connection, etc), and wants to skip the HTTP 1.1 Upgrade mechanism and
>> send
>>> "naked" HTTP 2.0 frames from the start (without TLS), I presume it should
>>> still send the session header? As worded above, the behavior is undefined.
>>> I'm guessing, the answer is yes..
>> 
>> That's the way I understood it...
>> 
>> And session header in that case tells that HTTP/2.0 is coming, not HTTP/1.x
> 
> In this case, the behavior is defined in the draft. Section 3.2 talks about the "prior knowledge" scenario, in which neither an Upgrade nor a TLS handshake occurs:
> 
> http://http2.github.io/http2-spec/#rfc.section.3.2
> "If starting HTTP/2.0 with prior knowledge, the client session header is sent upon connection establishment."
> 
>>> How does this work in light of the client/server session headers? Do we
>>> skip the client session header and send the server session header, followed
>>> by response frames? Or does the client have to wait to get the 101, and
>>> then send the client session header before the connection can proceed?
>> 
>> Of course, client has to wait for server session header or it sends
>> something designed to cause things to break...
> 
> However, in the Upgrade scenario, I think the draft is not precise. It follows from 3.8.4 that a SETTINGS frame MUST be the first frame sent by either party in a new session. Since the server session header *is* a SETTINGS frame (section 3.2), it follows that the first thing a server sends is its server session header. So strictly speaking, the server session header is not a response to the client session header. It is simply the first thing the server sends on a new session. In the Upgrade case, the server's session header goes out before the client's, so it is not a response. 
> 
> 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.
> 
> 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.
> 
> 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. 
> 
> 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).
> 
> Thanks,
> 
> Gabriel

--
Mark Nottingham   http://www.mnot.net/

Received on Wednesday, 17 April 2013 11:16:05 UTC