Re: Design Issue: Separate HEADERS and PRIORITY Frames, Eliminate HEADERS+PRIORITY

[William Chan (陈智昌) <[e-mail]>]

We discussed this previously and Roberto and I were both against the
removal of the priority field from the HEADERS+PRIORITY frame:
http://lists.w3.org/Archives/Public/ietf-http-wg/2013JanMar/1065.html, even
considering stream reprioritization.

I support adding a new additional PRIORITY frame for stream
reprioritization. That said, I'm in no hurry to write anything into the
spec. On the SPDY end we're planning on experimenting with prioritization
and when we have something to present with detailed explanations why, we
will do so. We presented the general ideas previously in the last interim
meeting and haven't finished implementation and experimentation.

Unless there's a reason this needs to be in the current http/2 draft sooner
rather than later, I'd rather punt on this discussion until we have
implementation experience that can guide this debate. I believe everyone
recognizes that people are interested in reprioritization. If we need to
put something in the spec, let's just add a new frame and then revisit
changing HEADERS+PRIORITY later.


On Tue, May 21, 2013 at 1:10 PM, James M Snell <[e-mail]> wrote:

> https://github.com/http2/http2-spec/issues/99
>
> With regards to the discussion over stream re-prioritization, I suggest:
>
> 1. Drop the HEADERS+PRIORITY frame type.
> 2. Create a new separate PRIORITY frame type whose payload is the
> Priority value, no frame-specific flags.
> 3. The PRIORITY frame becomes the only way to set/change the priority
> for a stream.
>
> If it is necessary to allow an endpoint to establish the priority of
> stream prior to actually initiating the stream, we can allow sending a
> PRIORITY frame before the initial HEADERS frame. Doing so would
> effectively reserve the stream id (in the same general manner
> PUSH_PROMISE does).
>
> The advantages of this approach are:
>
> 1. It eliminates any possible confusion and complexity about when to
> use HEADERS+PRIORITY vs. HEADERS
> 2. It provides a single way of setting/change stream priority (as
> opposed to using HEADERS+PRIORITY plus a separate CHANGE-PRIORITY
> frame)
>
>