Re: Clarification for RFC7231 CONNECT (section 4.3.6)

On Tue, Apr 28, 2015 at 3:38 PM, Nico Williams <nico@cryptonector.com> wrote:
> Section 4.3.6 of RFC7231 says:
>
>    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.
>
> I find the second sentence strange: if a proxy sends a body in a 2xx
> response to a CONNECT and the client ignores it, the client will... find
> the response body and pass it along to the application as application
> protocol data!
>
> Surely that's not really the intent when a proxy violates the first
> sentence of the quoted paragraph by sending a response body.
>
> Even if no known proxies send a response body in 2xx CONNECT responses,
> it seems more plausible that proxies do just that than that they include
> non-zero-length Content-Length but no response body.
>
> Also, it's not stated explicitly, but 2xx responses to CONNECT should
> have no body.
>
> Two possible errata spring to mind:
>
> a) explicitly state that 2xx responses to CONNECTs may have no body,

that part is already in the (other) rfc
http://tools.ietf.org/html/rfc7230#section-3.3.3

Zhong Yu
bayou.io


>
> b) relax the requirement for clients to be that they must ignore
> response bodies in 2xx CONNECT responses, but that they must still skip
> to the end of the response, body included when the proxy sends one.
>
> Before I submit them, I thought I'd ask on the list.  (No such errata
> have been filed yet.)
>
> This might seem academic, but I'm fixing a bug in a popular client that
> affects protocols tunneled over CONNECT where the server speaks first or
> doesn't wait to hear from the client before speaking (e.g, SSH).  In the
> process of fixing it I ran into the text quoted above, and it would be
> harder to remove handling of Content-Length / Transfer-Encoding for 2xx
> responses than to leave it in but ignore the body.  Obviously I can make
> this client implement the quoted requirement, but as I said, it seems
> quite wrong.
>
> Nico
> --
>

Received on Wednesday, 29 April 2015 15:38:25 UTC