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 8740Source of RFC: httpbis (app)
Errata ID: 6309
Status: Held for Document Update
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.
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
However, it's unclear whether the "any frame other than" language is to be construed as "more specific guidance."