RE: Expect: + Upgrade: = ...

Speaking as the HTTP server stack implementer, the best way, IMHO, is to mandate that:
1 - the server emit the 100 first followed by the 101.
2 - the client emit the entire request in HTTP/1.1 (which is a result of #1)

It is legal for the client to send the entity body without waiting for the 100.  Consequently, if the server were to send the 101 first then the server does not know whether the next set of bytes it receives (i.e. entity body) from the client were sent before or after the client got the 101.  This means the server side parser cannot deterministically parse the request stream.  By sending the 100 first, we guarantee that the client will emit the entity-body in HTTP/1.1.  Then the server sends the 101 and subsequent HTTP/2.0 bytes.  As soon as the server sends the 101, the server knows that the next inbound bytes will be HTTP/2.0 and as soon as the client receives the 101 it knows it can send HTTP/2.0 and that the next inbound bytes will be HTTP/2.0.

-----Original Message-----
From: Willy Tarreau [mailto:w@1wt.eu] 
Sent: Friday, September 6, 2013 12:13 PM
To: Martin Thomson
Cc: Ilari Liusvaara; Amos Jeffries; Roy T. Fielding; Michael Sweet; Daniel Stenberg; HTTP Working Group
Subject: Re: Expect: + Upgrade: = ...

On Fri, Sep 06, 2013 at 12:05:57PM -0700, Martin Thomson wrote:
> On 6 September 2013 11:52, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
> > So if server sends 101 and then 100, one direction of connection is
> > HTTP/1.1 and the other is HTTP/2.0 until the request is completed?
> 
> Presumably, yes.  But we shouldn't allow that.

In fact not really. The client requests an Upgrade and expects whatever it sees after the double CRLF following the 101 to be in the upgraded protocol. So it's not one direction in one version and the other one in another version, it's one side ready for 2.0 and the other side not yet aware of this readiness and waiting for the response to come.

Willy

Received on Friday, 6 September 2013 23:06:28 UTC