RFC 7540, "Hypertext Transfer Protocol Version 2 (HTTP/2)", May 2015

Note: This RFC has been obsoleted by RFC 9113

Note: This RFC has been updated by RFC 8740

Errata ID: 6309
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Mike Bishop
Date Reported: 2020-10-19
Held for Document Update by: Barry Leiba
Date Held: 2020-10-27

Section 5.1 says:

      Receiving any frame other than HEADERS or PRIORITY on a stream in
      this state MUST be treated as a connection error (Section 5.4.1)
      of type PROTOCOL_ERROR.

...and similar throughout the section

It should say:

      Receiving any frame defined in this document other than HEADERS
      or PRIORITY on a stream in
      this state MUST be treated as a connection error (Section 5.4.1)
      of type PROTOCOL_ERROR.  Frames of unknown types are ignored.

Notes:

Discovered via Chrome's GREASE experiment and discussed on-list, but never filed that I can find. The HTTP/2 RFC mandates tolerance of any unknown frame type, but also mandates rejection of frames which are not the few listed. The conservative solution in current deployments is, of course, to restrict sending extension frame types to open (and half-closed (remote)) streams. The text which should have been in the document to begin with, however, is that only frame types defined in the HTTP/2 specification were to be impacted by that restriction.

This is already stated in section 5.1:

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 (Section 5.4.1) of type PROTOCOL_ERROR. Note that PRIORITY can
be sent and received in any stream state. Frames of unknown types
are ignored.

However, it's unclear whether the "any frame other than" language is to be construed as "more specific guidance."

Report New Errata