- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Wed, 29 Apr 2015 16:00:36 -0700
- To: Nico Williams <nico@cryptonector.com>
- Cc: RFC Errata System <rfc-editor@rfc-editor.org>, julian.reschke@greenbytes.de, barryleiba@computer.org, Mark Nottingham <mnot@mnot.net>, ietf-http-wg@w3.org
On Apr 29, 2015, at 3:52 PM, Nico Williams <nico@cryptonector.com> wrote: > > On Wed, Apr 29, 2015 at 03:48:31PM -0700, Roy T. Fielding 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. > > 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? 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
Received on Wednesday, 29 April 2015 23:01:00 UTC