Re: [Technical Errata Reported] RFC7231 (4351)

> On Apr 29, 2015, at 1:20 PM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
> 
> 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 <nico@cryptonector.com>
> 
> 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.

REJECT

This was discussed extensively by the working group during the drafting
process.  The specification is correct.  Any application data sent after
the response is AFTER the response -- it is not part of the response body.

Sending either of the two header fields that would imply a response body
is a known interop failure, and thus MUST NOT be sent.  The fact that
some broken implementations are non-interoperable does not change the
requirement for interop.

....Roy

Received on Wednesday, 29 April 2015 22:48:54 UTC