Code change:
…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. 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. 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. "Highest ordered" implies some numerical rank-list of ordering, but we don't seem to clearly indicate whether older or newer requests receive higher numerical indices. It seems simples to just say "oldest" (or "newest", if that was the intent) rather than applying numerical ranking. Editors:
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. 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". [...] 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... I'm not a TLS expert. That said, if this is correct, would be lowercasing the two keywords be sufficient?
URL is for section 9.8
Change for 9.8 LGTM (as what might pass for a TLS expert).

Related discussion:
text: 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,