Re: PRIORITY flag on HEADERS Frame?

Would love to see if this change would be acceptable.

IMHO there are several immediate benefits:
- it reduces uncertainty in the frame size and layout
- it simplifies headers frame processing by restricting prioritization
events to priority frames
- it centralizes priority to a single frame type should we need to
replace / improve it in the future
- it saves a flag (yay!)

The only drawback I see would be that some existing implementations
that send priority on stream start would have to recode to emit two
fames instead of one. Receives don't even have to change if they don't
want to since it is effectively a no-op to not set an undefined flat.

On Mon, Dec 1, 2014 at 5:33 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> On 1 December 2014 at 14:28, Jeff Pinner <jpinner@twitter.com> wrote:
>> With the change from -15 to -16 to allow PRIORITY frames to be sent at
>> any time, why is the PRIORITY flag retained on the HEADERS frame?
>>
>> Was this an oversight or intentional?
>
> I can't claim intentional here, but I don't believe that broader
> changes were going to be acceptable.  Maybe we have to live with some
> extra complexity.  It does save a couple of bytes...

Received on Tuesday, 2 December 2014 03:20:10 UTC