Clarification for RFC7231 CONNECT (section 4.3.6)

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,

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 Tuesday, 28 April 2015 20:39:22 UTC