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: …to explain better for
[x] Section 9.4 Furthermore, using multiple connections can cause undesirable side effects in congested networks. Using larger number of multiple connections can also cause side effects in otherwise uncongested networks, because their aggregate and initially synchronized sending behavior can cause congestion that would not have been present if fewer parallel connections had been used. nit: "Using larger number of multiple connections" doesn't seem right, and possibly in more ways than just the singular/plural mismatch. Editors: URL [x] trailers and chunked The only general comment I have is that [Semantics] did such a good job of portraying the trailer section as a generic concept that I was surprised to see it presented as specific to the chunked transfer-encoding in this document. It seems to me (naively, of course), that when the content can accurately be delimited, whether by Content-Length or the chunked transfer-encoding, a trailer section could be read after the request or response and clearly distinguished from the start of a new request or response. I recognize that we have a significant deployed base to be mindful of backwards compatibility with, and so do not propose to recklessly add trailer sections everywhere. It might be worth some more prominent acknowledgment that in HTTP/1.1 the trailers section is limited to the chunked transfer-encoding, and discussion of why trailers are not usable in other HTTP/1.1 scenarios, though. Editors: The HTTP/1.1 message format does not allow adding trailers as a section following the message body. Trailers is allowed in chunked because the content itself is encoded into a format that concludes with an optional trailer section (within the message body). There is no possibility of generalizing this further for HTTP/1.x. [x] 2.2 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. [...] Given the previous procedure that gives as a permitted behavior to "consume the line without further processing", it seems like an attempt to get the server to ignore the field line would have succeeded if this procedure is followed? I suppose the important difference is that the field line is completely suppressed from any version of the message transmitted downstream, thus avoiding the opportunity for a different interpretation.