Re: Design Issue: Must Ignore Rule for Unknown Frame Types

[James M Snell <[e-mail]>]

Ok, then if we go with MUST Ignore, we need to be explicit about
requiring that unknown frame types cannot modify session / connection
state. The most significant effect of this is that new frame types
must not contain compressed header blocks that utilize the same shared
compression state as known frames. That does not rule out the use of
header compression in those frames, it just dictates that the state
management for those occur at a higher level in the stack.

On Thu, Apr 25, 2013 at 4:14 PM, Martin Thomson
<[e-mail]> wrote:
> If "MUST ignore", then it follows that "cannot modify session/connection state".
>
> I prefer "MUST ignore" because it allows for new frame types within a
> standardized negotiated protocol without fatal errors.  If you want to
> have new frame types modify session state, then you can negotiate a
> new protocol (HTTP/2.infinity)".
>
> BTW, that's a standard response we came up with informally at the
> Tokyo interim.  If someone wants to break the protocol, they are free
> to break their own because negotiating new protocols is going to be
> easy ... we hope.
>
> On 25 April 2013 15:58, James M Snell <[e-mail]> wrote:
>> https://github.com/http2/http2-spec/issues/80
>>
>> In the current draft (-02) we say, "Implementations MUST ignore
>> unsupported and unrecognized frame types." but we give no guidance
>> that I can find about handling unknown frames that potentially modify
>> session state. For example, suppose some extension comes up with a new
>> frame type that includes a compressed header block. The receiving
>> endpoint will have no way of interpreting the content, but if it
>> ignores the frame entirely, it's stored session state can unknowingly
>> fall out of sync with the sender.
>>
>> Recommendation: rather than a "MUST IGNORE" rule here, unknown and
>> unrecognized frame types ought to be a Session Error because the
>> receiver cannot determine whether and how those frames may have
>> changed the session state on the sending side. It would not be safe
>> for the receiver to continue attempting to communicate with the sender
>> on that session.
>>
>> This obviously has an impact on the extensibility of the framing
>> layer. In short, a sender would not be able to use a new frame type
>> unless it knows the receiver can interpret it. The only solution for
>> that would be to have some kind of negotiation occur where the sender
>> effectively ask the recipient if particular extensions are supported
>> (as part of the session header perhaps?)
>>