Code change:
The status-code element is a 3-digit integer code describing the result of the server's attempt to understand and satisfy the client's <del> corresponding request.  The rest of the response message is to be interpreted in light of the semantics defined for that status code. See status.codes for information about the semantics of status codes, including the classes of status code (indicated by the first digit), the status codes defined by this specification, considerations for the definition of new status codes, and the IANA registry. </del> <ins> corresponding request.  A recipient parses and interprets the remainder of the response message in light of the semantics defined for that status code, if it is understood, or in accordance with the class of that status code indicated by its first digit if it is not. HTTP's core status codes are defined in status.codes, along with the classes of status codes, considerations for the definition of new status codes, and the IANA registry for collecting such definitions. </ins> The reason-phrase element exists for the sole purpose of providing a textual description associated with the numeric status code, mostly

Related discussion:
text: A TLS implementation MAY, after sending a closure alert, close the connection without waiting for the peer to send its closure alert, generating an "incomplete close". [...] This is written as if it's imposing normative requirements on generic TLS implementations (not placing restrictions on what TLS implementations are suitable for HTTPS). Fortunately, these "MUST initiate" and "MAY close without waiting" requirements seem to already be present in RFC 8446... Editors: Rewritten by URL [x] Section 9.8 This SHOULD only be done when the application knows (typically through detecting HTTP message boundaries) that it has sent or received all the message data that it cares about. ...whereas this SHOULD does not have an obvious analogue in RFC 8446, and thus it would make sense to retain the BCP 14 keyword for. Editors: None of that reads well (it was imported from RFC2818). This is better rewritten as a factual statement of when it knows, as committed above. [x] Section 4 interpreted in light of the semantics defined for that status code. See Section 15 of [Semantics] for information about the semantics of status codes, including the classes of status code (indicated by the first digit), the status codes defined by this specification, In some sense it seems that the referenced status codes are defined by [Semantics], not "this specification". I was initially going to propose (in my PR) a change to "defined for", but that seems incorrect and I don't have a better proposal handy. Editors: URL [x] Section 5.2 (i.e., that has any field line value that contains a match to the obs-fold rule) unless [...] Since we don't include the obs-fold production as a component of any other production, and field-value excludes CRLF, it seems that any such field line value would already be in violation of the ABNF and thus forbidden. I don't really want to advocate for including obs-fold in the field-value production in -semantics, though, so maybe accepting this nit is the least bad choice here. Editors: I believe this is more than a nit. Opened URL [x] Section 9.2 MUST maintain a list of outstanding requests in the order sent and MUST associate each received response message on that connection to the highest ordered request that has not yet received a final (non- 1xx) response.