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

On 2014–04–03, at 2:16 PM, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> wrote:

> And anyone can ignore priority in HEADERS and PRIORITY.

Correct.

> 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. It’s 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 don’t 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.