Subject: handling bad priority parameters

From: Matthew Kerwin <[email-masked]>
Date: Fri, 22 Aug 2014 13:30:36 +1000

I'm currently working through stream prioritisation in draft-14, and I have
two questions. Sorry if they've been discussed already, I searched the
mailing list archives but couldn't find anything (at least back to around
the draft-10 era).

1. What's the appropriate reaction if a HEADERS or PRIORITY frame includes
an invalid stream dependency? i.e. too large, odd when it should be even,
etc? I can see a case for allowing future IDs into the tree, completely
ignoring bad priority data, or for throwing a stream error. Which should it
be?

​2. What do we do if we receive a trailing HEADERS ​frame that contains
priority info? §5.3 says: "A client can assign a priority for a new stream
by including prioritization information in the HEADERS frame that opens the
stream.  For an existing stream, the PRIORITY frame can be used to change
the priority." But nothing explicitly says what to do if the HEADERS frame
with the priority info isn't the HEADERS frame that opens the stream. I
would appreciate a bit of text either there or in §6.2 that clarifies the
point.

Cheers
-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: Martin Thomson <[email-masked]>
Date: Fri, 22 Aug 2014 10:52:03 -0700

> ignoring bad priority data, or for throwing a stream error. Which should it

My intent, which I failed to capture, was to say that if you don't
have priority state for the parent stream, the dependent stream
instead is given default priority (that means stream 0, weight 16).

> 2. What do we do if we receive a trailing HEADERS frame that contains
> priority info?

I think that we should fix that too.

https://github.com/http2/http2-spec/commit/620348d708aba641e4e09b0b7abd6960c199a764

---

From: Matthew Kerwin <[email-masked]>
Date: Sat, 23 Aug 2014 11:53:04 +1000

> instead is given default priority (that means stream 0, weight 16).
Understood. I guess it doesn't hurt anyone too much if the tree gets
mangled because of a desync.

> https://github.com/http2/http2-spec/commit/620348d708aba641e4e09b0b7abd6960c199a764

Much better, thanks.​