Subject: [Technical Errata Reported] RFC7231 (4351)

From: RFC Errata System <[email-masked]>
Date: Wed, 29 Apr 2015 13:20:54 -0700 (PDT)

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 <[email-masked]>

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

---

From: Nico Williams <[email-masked]>
Date: Wed, 29 Apr 2015 17:11:08 -0500

> Corrected Text

Thinking about it a bit more, I think what we should want to do is a)
relax the MUST NOT as to Content-Length (for clients and servers), b)
insist on the identity Transfer-Encoding (MUST NOT send
Transfer-Encoding) and explain why (clients exist that won't interop
otherwise), c) explain the intent (2xx CONNECT response bodies are
tunneled application data) and let client implementors decide if
ignoring Content-Length is the best way to get that effect.

Nico
--

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 29 Apr 2015 22:16:49 +0000

one thing here.

We're mixing language around servers and proxies.

CONNECT is intended only for a proxy, and in that respect it is acting 
like a server, but we should be consistent, and it would be more clear 
to only refer to proxy as the consumer of the CONNECT request and 
emitter of the response.  Then server can be unambiguously used to refer 
to the target of the CONNECT method processed by the proxy.

Otherwise it sounds like a proxy is forwarding a CONNECT message to a 
server, and the server is generating the response.

Adrien

------ Original Message ------
From: "Nico Williams" <[email-masked]>
To: "RFC Errata System" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>; 
"[email-masked]" <[email-masked]>; 
"[email-masked]" <[email-masked]>; "[email-masked]" 
<[email-masked]>; "[email-masked]" <[email-masked]>
Sent: 30/04/2015 10:11:08 a.m.
Subject: Re: [Technical Errata Reported] RFC7231 (4351)

---

From: Nico Williams <[email-masked]>
Date: Wed, 29 Apr 2015 17:23:11 -0500

> We're mixing language around servers and proxies.

The RFC already does this.  The old text says "servers", but clearly it
must mean "proxies".  I felt uneasy about this.

> CONNECT is intended only for a proxy, and in that respect it is

Mostly (see the beginning of section 4.3.6).

> acting like a server, but we should be consistent, and it would be
> more clear to only refer to proxy as the consumer of the CONNECT
> request and emitter of the response.  Then server can be
> unambiguously used to refer to the target of the CONNECT method
> processed by the proxy.

I agree.

> Otherwise it sounds like a proxy is forwarding a CONNECT message to
> a server, and the server is generating the response.

Nico
--

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 29 Apr 2015 15:48:31 -0700

> On Apr 29, 2015, at 1:20 PM, RFC Errata System <[email-masked]> wrote:
> 

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

---

From: Nico Williams <[email-masked]>
Date: Wed, 29 Apr 2015 17:52:34 -0500

> some broken implementations are non-interoperable does not change the

This isn't about the MUST NOT send requirement.  It's about the MUST
ignore requirement on clients.

Ignoring the Content-Length has the side-effect (which I assume was
intentional, but I wanted a clarification for it) that the 2xx CONNECT
response body is treated as application data.  Why ignore that which
must not be sent, and why ignore it if processing it and then treating
the response body as application data... has the same effect?

Nico
--

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 29 Apr 2015 16:00:36 -0700

> the response body as application data... has the same effect?

The header fields MUST be ignored -- not the bits after the response.
The response has no body!

That is what the spec says.  We don't need to clarify it further, and it
certainly isn't an erratum.

The second paragraph you quoted is about request bodies, not response bodies.
Changing it would be completely incorrect.

As I said, this was discussed extensively by the group.  The spec is correct.

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 30 Apr 2015 10:12:47 +1000

Folks - 

Please pare the distribution list down. 

From my standpoint —

This *was* discussed extensively on-list and we came to consensus; those who are proposing a change here should familiarise themselves with the issues:
  http://trac.tools.ietf.org/wg/httpbis/trac/ticket/250
  http://trac.tools.ietf.org/wg/httpbis/trac/ticket/251
… and related list discussion, starting here:
  https://lists.w3.org/Archives/Public/ietf-http-wg/2009AprJun/0261.html
… and continuing here:
  https://lists.w3.org/Archives/Public/ietf-http-wg/2010OctDec/0262.html

Even if there does turn out to be an interop problem here, I'm having trouble seeing how what's being proposed will fit into what the IETF considers to be an erratum.

Regards,

--
Mark Nottingham   https://www.mnot.net/

---

From: Nico Williams <[email-masked]>
Date: Wed, 29 Apr 2015 19:21:58 -0500

> The response has no body!

Clearly.  We're talking about proxies that nonetheless send one (see
responses on the list yesterday and today to my clarification request).

And why require clients to ignore that which must not be present, if
not because sometimes they are?

It's when a proxy sends Content-Length: and a response body [in a 2xx
response to CONNECT] that ignoring it has the effect of treating the
body as application data.  An effect that I agree is desirable, and so
that should be stated, rather than left implied.

> certainly isn't an erratum.

The spec can say what it says, but several people have asserted (in
responses on the list yesterday and today) that they've seen violations.

> Changing it would be completely incorrect.

Oh, I didn't mean to leave that out.  Yes, that's a braino.

Nico
--