Ben Kakuk's COMMENT on Messaging

[mnot]

---

• 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: #921

---

• 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.

---

• 2.2

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. [...]

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: #926

---

• Section 3.2

Recipients of an invalid request-line SHOULD respond with either a
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).

---

• Section 3.3

Supplying a default name for authority within the context of a
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.

---

• Section 5.1

The field line value
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: #927

---

• Section 9.8

TLS provides a facility for secure connection closure. When a valid
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 71e70d2

---

• 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.

NITS

---

• Section 4

The rest of the response message is to be
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: #922

---

• Section 5.2

A sender MUST NOT generate a message that includes line folding
(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 #923

---

• Section 9.2

A client that has more than one outstanding request on a connection
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: #928

[reschke]

Section 9.8

TLS provides a facility for secure connection closure. When a valid
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...

I'm not a TLS expert. That said, if this is correct, would be lowercasing the two keywords be sufficient?

[royfielding]

71e70d2 is for section 9.8

[martinthomson]

Change for 9.8 LGTM (as what might pass for a TLS expert).