- From: Nico Williams <nico@cryptonector.com>
- Date: Wed, 29 Apr 2015 17:11:08 -0500
- To: RFC Errata System <rfc-editor@rfc-editor.org>
- Cc: fielding@gbiv.com, julian.reschke@greenbytes.de, barryleiba@computer.org, mnot@mnot.net, ietf-http-wg@w3.org
On Wed, Apr 29, 2015 at 01:20:54PM -0700, RFC Errata System wrote: > 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. 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 --
Received on Wednesday, 29 April 2015 22:11:32 UTC