Re: Priority inside PUSH_PROMISE frames

On 2014–06–13, at 8:14 AM, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 12 June 2014 17:07, Roberto Peon <grmocg@gmail.com> wrote:
>> How otherwise would the client know how the server was prioritizing it?
> 
> 
> The point being - I think - that if the client cares, it should reprioritize.

I suggested this some time ago, as a generalized part of a specific proposal about zero priority weight.

Prioritization by the server should be either assigned some semantics, however hazy, or disallowed. Even if implementations fail to live up to the ideal due to simplicity or bugs, everyone will at least be reaching for the same goal.

I think it makes the most sense that every stream should have the same priority on both ends.

To reiterate my proposal, allowing PRIORITY zero, given a reprioritization policy and a rule against zombie streams, provides a way to ask whether a stream is desired by the other end without resorting to flow control hacks.

POST with Weight=0 implements EXPECT, a server response with Weight≠0 implements CONTINUE. PUSH with Weight=0 gives a client the opportunity to refuse a resource.

The flow control scheme requires adjusting a global setting.
It breaks separation of concerns.
It adds complexity to critical global state. BLOCKED was added just for this debugging.

The two mechanisms can even coexist. It’s true, POST/Weight=0, like EXPECT requires the client to opt-in, but given that, the result is still superior: the initial window-full of upload is avoided. POST/Weight=0 doesn’t carry CONTINUE’s baggage because it’s part of a strictly optional system, not a full-fledged response: proxies can preemptively return a CONTINUE-equivalent without actually breaking the proposed semantics.

Received on Friday, 13 June 2014 02:27:51 UTC