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

From: James M Snell <[email-masked]>
Date: Thu, 25 Apr 2013 15:58:39 -0700

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?)

---

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Apr 2013 16:14:37 -0700

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.

---

From: James M Snell <[email-masked]>
Date: Thu, 25 Apr 2013 16:20:51 -0700

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.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Thu, 25 Apr 2013 21:56:38 -0700

I think this is a good clarification.