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

Re: Diminishing priorities in proposal

From: David Krauss <potswa@gmail.com>
Date: Thu, 17 Apr 2014 09:14:48 +0800
Cc: Mark Nottingham <mnot@mnot.net>, Jeff Pinner <jpinner@twitter.com>, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <03BE140B-A53D-4562-AC59-9D8AD35CEE5D@gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>

On 2014–04–17, at 7:21 AM, Martin Thomson <martin.thomson@gmail.com> wrote:

> So yes, there is a problem.  The problem is premature loss of
> information.  

Well, the other problem is that the revision (pull request) still mentions dependencies in the CLOSED state, so something’s gotta give.

> We have to allow servers to limit their state commitment, and having a
> specified practice for handling a very common case somewhat gracefully
> is a good idea.  

It’s a good idea, but not necessarily a must-have for an initial release. The amount of state is small. I think it can be managed well enough. Perhaps a LRU cache is a good approximation of behavior?

> Including a warning about the consequences of early
> tree pruning is probably the best that can be done.

A set of guidelines for clients to judge the validity of a closed stream as a dependency would be nice. I’m not even sure how to specify this, though. (And I didn’t have any idea how to maintain the set of priority groups, either.) The server ideally should maintain a closed stream/priority group for each tab, and the client re-prioritizes those as the user clicks different tabs. But, there is no limit to the number of tabs in a window, and sloppy users really do open a lot.

I recall my earlier proposal where the server sends a reply PRIORITY to override a client request. This could be a valid pattern for any received PRIORITY that the server cannot service…
Received on Thursday, 17 April 2014 01:15:33 UTC

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