Re: Priority inside PUSH_PROMISE frames

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

> On 12 June 2014 19:00, David Krauss <potswa@gmail.com> wrote:
>> To reiterate my proposal, allowing PRIORITY zero
> 
> I think that you are describing something that is different to what
> Herve proposed.  

Herve proposed that PUSH_PROMISE priority should be applied to the client-side state.

It’s a small extrapolation to say that if the server ever sends priority info, the client interprets it in the same way, and perhaps requests a priority change in response. I.e., there should always be identical prioritization on both sides.

Otherwise, where server-sent priority has no defined meaning, it should be illegal. This is not fertile ground for application-defined protocols. If a server-side application really wants to manipulate priority (which may decide how clients or client-side proxies allocate bandwidth), it should arrange for the client to adjust it.

The weight-zero business is less important, but…

> It's also more complex to implement correctly than
> even that trivial change, and that was not found to have sufficient
> interest.  Given the amount of grief we're getting over priority; I'm
> wary of these sorts of proposals.

Prioritization is all optional. My proposal is designed to avoid adding complexity to minimal implementations. I wouldn’t be proposing this except to solve problems, including that flow control is also difficult to implement, especially as flow control throttling may lead to priority inversion (BLOCKED et al). Simplicity is absolutely the motivation.

Received on Saturday, 14 June 2014 01:16:53 UTC