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

[Tatsuhiro Tsujikawa <[e-mail]>]

Hi,

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

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





> Thanks
>