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

Which is why we could allow for the client sending the PRIORITY frame
*before* the initial HEADERS frame.



On Tue, May 21, 2013 at 9:31 AM, Roberto Peon <grmocg@gmail.com> wrote:
> 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)
>>
>

Received on Tuesday, 21 May 2013 16:34:29 UTC