Subject: PRIORITY flag on HEADERS Frame?

From: Jeff Pinner <[email-masked]>
Date: Mon, 1 Dec 2014 16:28:39 -0800

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 1 Dec 2014 15:33:11 -1000

> 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...

---

From: Jeff Pinner <[email-masked]>
Date: Mon, 1 Dec 2014 19:19:43 -0800

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.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 2 Dec 2014 16:20:41 +1100

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 <[email-masked]> wrote:
> 

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

---

From: Jeff Pinner <[email-masked]>
Date: Mon, 1 Dec 2014 21:33:40 -0800

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

When we were trying to constrain the amount of server state required
by only allowing PRIORITY on open streams there was no where else to
put it.

Willing yes, but there weren't other options.

> 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.

Complete agree -- either this is an easy "yep, we should clean that
up" or we shouldn't bother.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 1 Dec 2014 21:25:00 -1000

> 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.

https://github.com/http2/http2-spec/issues/663

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 4 Dec 2014 03:34:22 +1100

On 2 December 2014 at 16:20, Mark Nottingham <[email-masked]> wrote:

> - it needs pretty much universal acclaim to get through.

Individual acclaim here.

I know it makes procedural hassles.... but if not done now it will be a
minor hassle for decades.

-- 
Greg Wilkins <[email-masked]>  @  Webtide - *an Intalio subsidiary*
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.

---

From: Brad Fitzpatrick <[email-masked]>
Date: Wed, 3 Dec 2014 08:41:21 -0800

> minor hassle for decades.

Agreed. And it simplifies the spec in both length and having fewer ways to
do the same thing.

---

From: Patrick McManus <[email-masked]>
Date: Wed, 3 Dec 2014 09:22:32 -0800

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 <[email-masked]> wrote:

> 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.
>

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 3 Dec 2014 13:40:24 -0800

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 <[email-masked]>
wrote:

>> 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.
>>

---

From: "Kulkarni, Saurabh" <[email-masked]>
Date: Wed, 3 Dec 2014 16:00:27 -0600

+1 to not doing anything.

- Saurabh

From: Ryan Hamilton <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, December 3, 2014 at 1:40 PM
To: Patrick McManus <[email-masked]<mailto:[email-masked]>>
Cc: Mark Nottingham <[email-masked]<mailto:[email-masked]>>, Jeff Pinner <[email-masked]<mailto:[email-masked]>>, HTTP Working Group <[email-masked]<mailto:[email-masked]>>
Subject: Re: PRIORITY flag on HEADERS Frame?
Resent-From: <[email-masked]<mailto:[email-masked]>>
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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:
Jeff,

Regards,

> On 2 Dec 2014, at 11:28 am, Jeff Pinner <[email-masked]<mailto:[email-masked]>> wrote:
>

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 4 Dec 2014 15:54:48 +1100

<https://github.com/http2/http2-spec/issues/663>

Based on the responses so far, I'd say we're not going to get an easy win here. 

I'm closing this but marking as revisit-upon-change.

Thanks,

> On 2 Dec 2014, at 4:20 pm, Mark Nottingham <[email-masked]> wrote:
> 
> Jeff,
>