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: Regardless, though, it seems like the text of the guidance as written (not quoted above) reads like it is setting us up for vulnerabilities in the presence of non-compliant (or HTTP/1.0?) implementations in the request chain. We might want to put in a bit more explanation of how the stated procedure avoids the vulnerability. Editors: [x] Section 3.2 400 (Bad Request) error or a 301 (Moved Permanently) redirect with the request-target properly encoded. [...] (I assume 301 rather than 308 was an intentional choice for maximum compatibility with old/broken clients.) Editors: This requirement existed long before 308 was minted. In any case, 301 would be preferred since we don't want to assume too much about why a non-GET request method is being used with an invalid request-line (usually meaning that the client failed to encode spaces in the hypertext reference). [x] Section 3.3 secured connection is inherently unsafe if there is any chance that the user agent's intended authority might differ from the selected default. A server that can uniquely identify an authority from the request context MAY use that identity as a default without this risk. Is the contents of the TLS SNI extension sufficient request context to uniquely identify an intended authority? Editors: Maybe. Using a certificate that is specific to that authority (one that can't be shared by multiple origins and thus was definitely chosen by the client) would be sufficient. We don't need to define this further. [x] Section 5.1 does not include any leading or trailing whitespace: OWS occurring before the first non-whitespace octet of the field line value or after the last non-whitespace octet of the field line value ought to be excluded by parsers when extracting the field line value from a field line. I have in general tried to refrain from commenting on the extensive use of the phrase "ought to" in this group of documents, but this particular scenario seems like a strong candidate for a BCP 14 keyword. Editors: [x] Section 9.8 closure alert is received, an implementation can be assured that no further data will be received on that connection. TLS implementations MUST initiate an exchange of closure alerts before closing a connection.