W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Zero weight for 100 CONTINUE, instead of flow control

From: David Krauss <potswa@gmail.com>
Date: Thu, 3 Apr 2014 15:13:08 +0800
Message-Id: <E2EF55F4-C69B-47CC-A2E3-F5404318A05C@gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>

On 20140403, at 2:16 PM, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> wrote:

> And anyone can ignore priority in HEADERS and PRIORITY.


> Both endpoints MUST support flow control and breakage leads to the connection error.
> On the other hand, PRIORITY mechanism is completely optional feature of the protocol.
> Simple implementation may just omit to implement it
> Therefore, only flow control can do the better job which expect header did previously.

EXPECT is client-initiated. Its only mandatory for the server. Flow control throttling is server-initiated and mandatory for the client, who is kept blind.

To roughly emulate CONTINUE behavior, the client may wait for the initial settings frame to set the initial window properly. It may wait for a possible RST_STREAM before beginning the request body. It may wait for receipt of the first data frame before transmitting a second frame, but that would be a poor strategy because receipts dont come from the origin server. Any of this behavior has no particular support in the protocol, may be hard to express properly by the application, and reduces performance.

Whereas EXPECT allows a client to defer a particular upload entirely, flow control throttling will result in a partial upload, unless one of the aforementioned tricks is employed. (Actually, only unless the client uses a timeout to wait for RST_STREAM.)

A PRIORITY handshake allows the client to check before uploading anything, as with EXPECT. Or it can preemptively send something, or query at any time whether the server wants more data.

Come to think of it, there is a strong UX argument for doing this with priorities and not something else. When uploading a photo album, Facebook provides live previews. Server-specified priority would help the client upload files with complete previews appearing at the earliest opportunity, yet allowing some number of actual servers to be represented by a single origin. (I have not verified that Facebook in fact uses more than one connection; it could just be a painted-on effect.)

>   Of course, you can propose a text or two to make PRIORITY mandatory and which part.

I suggested that a frame with PRIORITY_GROUP and zero weight must elicit either a response PRIORITY or a RST_STREAM; in fact that is the entirety of my proposal. The difference the weight domain 0..255 or 1..256 is actually immaterial since a stream is not allowed to be weighted at zero.

Detecting such a PRIORITY and generating a reflexive response should add little complexity to any implementation.

Received on Thursday, 3 April 2014 07:13:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:29 UTC