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

This separation would introduce a race where the server may start sending
content before it knows the appropriate priority.

That would be bad.
On May 21, 2013 9:13 AM, "James M Snell" <jasnell@gmail.com> 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)
>
>