[Technical Errata Reported] RFC7231 (4351)

[RFC Errata System <[e-mail]>]

The following errata report has been submitted for RFC7231,
"Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7231&eid=4351

--------------------------------------
Type: Technical
Reported by: Nicolas Williams <[e-mail]>

Section: 4.3.6

Original Text
-------------
   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.

Corrected Text
--------------
   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.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7231 (draft-ietf-httpbis-p2-semantics-26)
--------------------------------------
Title               : Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
Publication Date    : June 2014
Author(s)           : R. Fielding, Ed., J. Reschke, Ed.
Category            : PROPOSED STANDARD
Source              : Hypertext Transfer Protocol Bis
Area                : Applications
Stream              : IETF
Verifying Party     : IESG