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

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 <jasnell@gmail.com> 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?)
>

Received on Thursday, 25 April 2013 23:15:04 UTC