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

Re: Priority inside PUSH_PROMISE frames

From: David Krauss <potswa@gmail.com>
Date: Sat, 14 Jun 2014 09:16:02 +0800
Cc: (wrong string) ‎[ietf-http-wg@w3.org]‎" <ietf-http-wg@w3.org>
Message-Id: <B286030C-2D5F-4A22-BA04-152548639712@gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>

On 20140614, 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.

Its 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 wouldnt 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

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