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

Re: h2 priority

From: Patrick McManus <mcmanus@ducksong.com>
Date: Tue, 2 Sep 2014 11:28:00 -0400
Message-ID: <CAOdDvNrpUDeQReRWx-2bVaPLfKX+oy-Ab9f92BpFaz6Vp+cZHg@mail.gmail.com>
To: "Roy T. Fielding" <fielding@gbiv.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Hi Roy,

On Sun, Aug 31, 2014 at 7:06 PM, Roy T. Fielding <fielding@gbiv.com> wrote:

> The reason I did not go into any more detail than that is because the
> priority information is only a suggestion, like in h2.  Defining how
> the recipient is going to reprioritize its stack based on existing
> streams is an implementation detail behind the HTTP interface: wishful
> thinking and untestable (because it is only a suggestion).  Editorially,
> section 5.3 belongs in an appendix, or as a separate spec that has time
> to ruminate on the balance between weighted streams and various
> response characteristics.

Editorially and organizationally I think you're right but am happy to defer
to the editor. As a matter of content, I think the fairly complicated
scheme is well justified in terms of identified problems spdy has shown
with using just a few bits of weight (aggregation of lots of clients, dash
like dependencies, etc..)

> > 6.2.  HEADERS
> >
> Priority is a suggestion.

imo it is only really a suggestion in the sense that it is untestable.
Priority is a core piece of h2, because h2 introduces mux and a
non-prioritized mux is worse than h1.

>   Sending it only within a separate frame
> type incurs an additional overhead of 64bits, only when it is sent,
> assuming we also allow PRIORITY frames to initiate a stream.

roberto suggested basically that not too long ago - tracked as
https://github.com/http2/http2-spec/issues/347 ..
Received on Tuesday, 2 September 2014 15:28:27 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:10 UTC