Re: PRIORITY flag on HEADERS Frame?

+1 to not doing anything.

- Saurabh

From: Ryan Hamilton <rch@google.com<mailto:rch@google.com>>
Date: Wednesday, December 3, 2014 at 1:40 PM
To: Patrick McManus <pmcmanus@mozilla.com<mailto:pmcmanus@mozilla.com>>
Cc: Mark Nottingham <mnot@mnot.net<mailto:mnot@mnot.net>>, Jeff Pinner <jpinner@twitter.com<mailto:jpinner@twitter.com>>, HTTP Working Group <ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>>
Subject: Re: PRIORITY flag on HEADERS Frame?
Resent-From: <ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>>
Resent-Date: Wednesday, December 3, 2014 at 1:41 PM

I completely agree with what Patrick said. We're quite late in the process to be considering features likes this. If there were some critical issue to be fixed by doing this, that would be one thing, but this smells like bikeshedding to me.

On Wed, Dec 3, 2014 at 9:22 AM, Patrick McManus <pmcmanus@mozilla.com<mailto:pmcmanus@mozilla.com>> wrote:
I don't think we should take this change. We've deferred other nice-to-haves on the basis of where we are in the pipeline and that should be what happens here too. There is no particular reason to think that this will be the last one and should be treated specially.

breaking changes reduce the value of the wg last call review that has already happened and weaken the value of the interop testing that has been completed when considering IESG last call. Discipline is the better route here.

-P


On Mon, Dec 1, 2014 at 9:20 PM, Mark Nottingham <mnot@mnot.net<mailto:mnot@mnot.net>> wrote:
Jeff,

This seems like an optimisation -- everyone (including you) were willing to have the flag there beforehand.

It doesn't cause any security or interop problems, so I'm inclined to hold this change to the same bar as similar ones brought up recently -- it needs pretty much universal acclaim to get through.

Who supports this change, and is anyone against it?

Regards,


> On 2 Dec 2014, at 11:28 am, Jeff Pinner <jpinner@twitter.com<mailto: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?
>
> IIRC we added the flag there because of the race condition where you
> couldn't send priority information for a stream that wasn't yet open
> and need a HEADERS frame to open the stream.
>
> Now that you can send the PRIORITY frame before the HEADERS that opens
> the stream there is no need to append the priority information and the
> parsing of the HEADERS frame can be simplified.
>
> - Jeff
>

--
Mark Nottingham   https://www.mnot.net/