Re: HTTP 2.0 "Upgrade" flow

++

-=R


On Tue, Apr 16, 2013 at 6:10 PM, 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
>