search

summerwind / h2spec

A conformance testing tool for HTTP/2 implementation.
MIT License
653 stars 71 forks source link

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

Open LPardue opened 2 years ago

LPardue commented 2 years ago

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 commented 2 months ago

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