Supporting the new document for HTTP/2 (RFC 9113)

[LPardue]

In June 2022, a whole set of new HTTP RFCs were published. Many of these were rewrites of existing specifications, alongside the new HTTP/3 and QPACK drafts. Part of this cluster of work was a rewrite of HTTP/2, published as RFC 9113, which obsoletes RFC 7540.

RFC 9113 is a rewrite that attempts to maintain a lot of what was already defined in HTTP/2. Changes are summarized in https://www.rfc-editor.org/rfc/rfc9113.html#appendix-B

Appendix B. Changes from RFC 7540

This revision includes the following substantive changes:

• Use of TLS 1.3 was defined based on [RFC8740], which this document
  obsoletes.

• The priority scheme defined in RFC 7540 is deprecated.
  Definitions for the format of the PRIORITY frame and the priority
  fields in the HEADERS frame have been retained, plus the rules
  governing when PRIORITY frames can be sent and received, but the
  semantics of these fields are only described in RFC 7540. The
  priority signaling scheme from RFC 7540 was not successful. Using
  the simpler signaling in [HTTP-PRIORITY] is recommended.

• The HTTP/1.1 Upgrade mechanism is deprecated and no longer
  specified in this document. It was never widely deployed, with
  plaintext HTTP/2 users choosing to use the prior-knowledge
  implementation instead.

• Validation for field names and values has been narrowed. The
  validation that is mandatory for intermediaries is precisely
  defined, and error reporting for requests has been amended to
  encourage sending 400-series status codes.

• The ranges of codepoints for settings and frame types that were
  reserved for Experimental Use are now available for general use.

• Connection-specific header fields -- which are prohibited -- are
  more precisely and comprehensively identified.

• Host and ":authority" are no longer permitted to disagree.

• Rules for sending Dynamic Table Size Update instructions after
  changes in settings have been clarified in Section 4.3.1.

Editorial changes are also included. In particular, changes to
terminology and document structure are in response to updates to core
HTTP semantics [HTTP]. Those documents now include some concepts
that were first defined in RFC 7540, such as the 421 status code or
connection coalescing.

I'd like to consider how h2spec and can be tweaked to accomodate both RFC 7540 and RFC 9113. I'm happy to volunteer some cycles but didn't want to start off in the wrong direction, hence opening this issue.

[nitely]

Note section 5.1 close state changed:

An endpoint MUST NOT send frames other than PRIORITY on a closed stream. An endpoint MAY treat receipt of any other type of frame on a closed stream as a connection error (Section 5.4.1) of type STREAM_CLOSED, except as noted below.

Does this mean received frames on a closed stream no longer MUST be treated as stream/connection error depending on how it got closed (RST_STREAM/END_STREAM)?