Re: [Technical Errata Reported] RFC7231 (4351)

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" <nico@cryptonector.com>
To: "RFC Errata System" <rfc-editor@rfc-editor.org>
Cc: "fielding@gbiv.com" <fielding@gbiv.com>; 
"julian.reschke@greenbytes.de" <julian.reschke@greenbytes.de>; 
"barryleiba@computer.org" <barryleiba@computer.org>; "mnot@mnot.net" 
<mnot@mnot.net>; "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Sent: 30/04/2015 10:11:08 a.m.
Subject: Re: [Technical Errata Reported] RFC7231 (4351)

>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:18:44 UTC