- From: Willy Tarreau <w@1wt.eu>
- Date: Sat, 7 Sep 2013 07:18:56 +0200
- To: Osama Mazahir <OSAMAM@microsoft.com>
- Cc: Martin Thomson <martin.thomson@gmail.com>, Ilari Liusvaara <ilari.liusvaara@elisanet.fi>, Amos Jeffries <squid3@treenet.co.nz>, "Roy T. Fielding" <fielding@gbiv.com>, Michael Sweet <msweet@apple.com>, Daniel Stenberg <daniel@haxx.se>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <20130907051856.GF7113@1wt.eu>
Hi, On Fri, Sep 06, 2013 at 11:04:19PM +0000, Osama Mazahir wrote: > 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. This is a very good point, I didn't think about it. > 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. I'm perfectly fine with this. Willy
Received on Saturday, 7 September 2013 05:21:11 UTC