Code change:
received prior to the request-line. A sender MUST NOT send whitespace between the start-line and the <del> first header field.  A recipient that receives whitespace between the start-line and the first header field MUST either reject the message as invalid or consume each whitespace-preceded line without further processing of it (i.e., ignore the entire line, along with any subsequent lines preceded by whitespace, until a properly formed header field is received or the header section is terminated). The presence of such whitespace in a request might be an attempt to trick a server into ignoring that field line or processing the line after it as a new request, either of which might result in a security vulnerability if other implementations within the request chain interpret the same message differently.  Likewise, the presence of such whitespace in a response might be ignored by some clients or cause others to cease parsing. </del> <ins> first header field. A recipient that receives whitespace between the start-line and the first header field MUST either reject the message as invalid or consume each whitespace-preceded line without further processing of it (i.e., ignore the entire line, along with any subsequent lines preceded by whitespace, until a properly formed header field is received or the header section is terminated).  Rejection or removal of invalid whitespace-preceded lines is necessary to prevent their misinterpretation by downstream recipients that might be vulnerable to request smuggling (request.smuggling) or response splitting (response.splitting) attacks. </ins> When a server listening only for HTTP request messages, or processing what appears from the start-line to be an HTTP request message,

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.