W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2020

[Errata Held for Document Update] RFC7540 (6309)

From: RFC Errata System <rfc-editor@rfc-editor.org>
Date: Tue, 27 Oct 2020 16:04:48 -0700 (PDT)
To: mbishop@evequefou.be, mike@belshe.com, fenix@google.com, martin.thomson@gmail.com
Cc: barryleiba@computer.org, iesg@ietf.org, ietf-http-wg@w3.org, rfc-editor@rfc-editor.org
Message-Id: <20201027230448.6F226F40709@rfc-editor.org>
The following errata report has been held for document update 
for RFC7540, "Hypertext Transfer Protocol Version 2 (HTTP/2)". 

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6309

--------------------------------------
Status: Held for Document Update
Type: Technical

Reported by: Mike Bishop <mbishop@evequefou.be>
Date Reported: 2020-10-19
Held by: Barry Leiba (IESG)

Section: 5.1

Original Text
-------------
      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

Corrected Text
--------------
      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."

--------------------------------------
RFC7540 (draft-ietf-httpbis-http2-17)
--------------------------------------
Title               : Hypertext Transfer Protocol Version 2 (HTTP/2)
Publication Date    : May 2015
Author(s)           : M. Belshe, R. Peon, M. Thomson, Ed.
Category            : PROPOSED STANDARD
Source              : Hypertext Transfer Protocol Bis APP
Area                : Applications
Stream              : IETF
Verifying Party     : IESG
Received on Tuesday, 27 October 2020 23:05:15 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 27 October 2020 23:05:16 UTC