Zero weight for 100 CONTINUE, instead of flow control

>> #436 Enable weight of 0.
>> 
>> Not a lot of feedback here.  Potentially disruptive.
> 
> … and unless we see discussion on the list very soon, it’s not going to make it into this implementation draft.

Oh, I didn’t know of the issue, but I was just going to ask about this!

It’s a better replacement for 100 CONTINUE than hacking flow control. (See my previous message, "Flow control protocol redundancy.”)

Sending a POST with a weight of 0 may notify a server that the sender is unsure whether to proceed. This matches the client-initiated semantic of waiting for CONTINUE.

The disruption can be quite minimal, because a zero-weight condition need not be persistent. Say that an endpoint receiving a zero weight must respond with either a PRIORITY or a RST_STREAM.

Unlike CONTINUE, this does not contort the protocol and rely on specific header processing. Default behavior to always resume the stream (for servers) or discontinue it (for clients) is reasonable for any ignorant application-level software.

I really don’t like the idea of using flow control to force the other end to stop. It does not offer appropriate guarantees, it relies on default settings, and it’s a violation of network layering principles. Just as CONTINUE is too high-level for what it’s supposed to do, flow control is too low-level.

Received on Tuesday, 1 April 2014 19:20:09 UTC