Subject: Clarify some handling about extension frame and unknown frame on HTTP/2

From: 蕭雋涵 <[email-masked]>
Date: Sat, 21 Jan 2017 12:02:34 +0800

It's related to https://tools.ietf.org/html/rfc7540#section-5.5 Extending
HTTP/2 and a test case for it
https://github.com/summerwind/h2spec/blob/master/5_5.go#L75-L102

The fourth paragraph said

> Implementations MUST ignore unknown or unsupported values in all
> extensible protocol elements. Implementations MUST discard frames
> that have unknown or unsupported types.

and it also said

> extension frames that appear in the middle of a header block are not
> permitted;
> these MUST be treated as a connection error of type PROTOCOL_ERROR.

So when one end point received one unknown frame in the middle of header
block,
I'm not sure what's the correct way to handle the frame with following two
options.
- the end point should drop the frame without any error
- the end point should close the connection with protocol error.

There is also one paragraph related to this that support the first option.
https://tools.ietf.org/html/rfc7540#section-5.1
at second from the last paragraph

> In the absence of more specific guidance elsewhere in this document,
> implementations SHOULD treat the receipt of a frame that is not
> expressly permitted in the description of a state as a connection
> error of type PROTOCOL_ERROR. Note that PRIORITY can
> be sent and received in any stream state. Frames of unknown types
> are ignored.

That said frames of unknown types should ignore and not treat as protocol
error.

So I think each the option make sense to me, and want to clarify for which
would be the best option.

Thanks

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Sat, 21 Jan 2017 17:22:50 +0900

Hi,

On Sat, Jan 21, 2017 at 1:02 PM, 蕭雋涵 <[email-masked]> wrote:

> HTTP/2 and a test case for it https://github.com/
> summerwind/h2spec/blob/master/5_5.go#L75-L102
>
​My understanding is that unknown frame type must be ignored except for
those which are received in the middle of header block.   The unknown frame
type appearing in the middle of header block must be treated as connection
error.

​Best regards,
Tatsuhiro Tsujikawa​

---

From: Cory Benfield <[email-masked]>
Date: Sat, 21 Jan 2017 13:50:41 +0000

> On 21 Jan 2017, at 08:22, Tatsuhiro Tsujikawa <[email-masked]> wrote:
> 
> ​My understanding is that unknown frame type must be ignored except for those which are received in the middle of header block.   The unknown frame type appearing in the middle of header block must be treated as connection error.

This is correct. A header block must always be a HEADERS frame, followed by zero or more CONTINUATION frames until one of these frames is marked with the END_HEADERS. If an unknown frame appears in that sequence, that violates the HEADERS rules, and so is a connection error.

Cory

---

From: 蕭雋涵 <[email-masked]>
Date: Sun, 22 Jan 2017 10:55:08 +0800

Hi Cory and Tatshuhiro,

Thanks for your detailed and clear explanation!
So the rule “never contains other frame in header blocks” had the higher priority than "drop unknown frame".

> Cory Benfield <[email-masked]> 於 2017年1月21日 下午9:50 寫道：
> 
> 
>> On 21 Jan 2017, at 08:22, Tatsuhiro Tsujikawa <[email-masked] <mailto:[email-masked]>> wrote:
>>