RFC 7231, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", June 2014

Note: This RFC has been obsoleted by RFC 9110

Errata ID: 4351
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Nicolas Williams
Date Reported: 2015-04-29
Rejected by: Barry Leiba
Date Rejected: 2015-06-01

Section 4.3.6 says:

   A server MUST NOT send any Transfer-Encoding or Content-Length header
   fields in a 2xx (Successful) response to CONNECT.  A client MUST
   ignore any Content-Length or Transfer-Encoding header fields received
   in a successful response to CONNECT.

   A payload within a CONNECT request message has no defined semantics;
   sending a payload body on a CONNECT request might cause some existing
   implementations to reject the request.

It should say:

   Historically no semantics have been defined for request and 2xx
   (Successful) response bodies for CONNECT, but nonetheless some
   clients and some servers do use request and 2xx response bodies.

   Servers MUST NOT send a response body in a 2xx (Successful)
   response to CONNECT.  Because some proxies send an initial flight
   of tunneled application data in 2xx response bodies, clients MUST
   accept response bodies in 2xx responses to CONNECT, and MUST
   treat the response body as the initial flight of application data.

   Servers that receive a CONNECT request body SHOULD treat it as the
   initial flight of tunneled application data.

Notes:

Implementing the original text ("A client MUST ignore...") has the effect
that the client will leave in the lower layer's buffer any 2xx CONNECT
response body, and when the Transfer-Encoding is the identity, then this
will have the effect that the 2xx response body is seamlessly prepended
to the tunneled application data in the server-to-client direction.
It seems almost like this was the intent of the original text, but if so,
then it would be much better to state this than to describe one possible
implementation approach.

Also, it seems rather unlikely that ignoring the Transfer-Encoding for any
TE other than the identity. If the proxy really did use a compression
or chunked transfer encoding, then ignoring this on the client side
(and prepending the encoded 2xx response body to the server-to-client
tunneled application data) would quite clearly be wrong.

It also seems that some clients send the first flight of tunneled
application data in a CONNECT request body. While historically the
semantics of CONNECT request and 2xx response bodies have not been
defined, it is worth pointing out that [it appears, so I'm told; see
below] some clients and some proxies rely on CONNECT request and 2xx
response bodies bearing the first flight of tunneled application data,
and if so, then the RFC should mention it. I'm not sure how much
evidence we can demand for such behaviors, but the RFC demands behavior
that implies the intent described in this erratum and gives no evidence
to support the need for such behavior, therefore it seems much better
to describe the previously-implied intent explicitly and continue with
a little-or-no-evidence approach that should nonetheless yield the most
interoperability.

Finally, I asked for clarification on the HTTPbis list, and the answers
I received indicate that the intent may have been as described in
these notes.

See https://lists.w3.org/Archives/Public/ietf-http-wg/2015AprJun/0260.html
and follow-ups.
--VERIFIER NOTES--
This is a change request, not an errata report. Such changes can be proposed in the working group's issue tracker, here:
https://github.com/httpwg/http11bis/issues

Report New Errata