Re: Clarification for RFC7231 CONNECT (section 4.3.6)

On Wed, Apr 29, 2015 at 07:01:20AM +0200, Willy Tarreau wrote:
> On Tue, Apr 28, 2015 at 03:38:58PM -0500, Nico Williams wrote:
> > 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.
> 
> In fact it's worse. I've long seen proxies sending various content-length
> values in response to CONNECT. Some send content-length:0, others send
> 1 million etc... I'm pretty sure they used to do that to workaround broken
> intermediaries which ignore the method and only follow content-length, and
> used to let a lot of data pass through. I think the text above is well

It sounds like the desired effect is to have any response body in a 2xx
response get treated as application data to be prepended to the
subsequent server->client stream.

If this was the desired effect, then the RFC should have said so.

Ignoring Content-Length has that effect for identity Transfer-Encodings,
but it does NOT for non-identity Transfer-Encodings!

Ignoring Content-Length is only one way to have that effect anyways.
The other is to properly parse the 2xx response, including the body, and
then prepend the body's contents to the server->client stream in the
tunnel.  I don't see why the RFC should describe the implementation
design when there is more than one possible design -- the RFC should
describe behavior.

(Ironically, ignoring Content-Length is probably the easiest way to
implement this behavior in the client I mentioned earlier, because after
reading and parsing the header one byte at a time, the client can leave
the body in the lower layer's buffers to be found by the post-CONNECT
code.  The alternative is to extract the body and copy it to the buffer
used by the post-CONNECT code, which turns out to be a bit more
complicated.)

Presumably the same sort of considerations go for CONNECT request
bodies.  Perhaps the client is sending its first flight of application
data in the CONNECT request body, so the proxy should immediately send
it to the target when the CONNECT succeeds.  This really needs to be
described if it is intended!

> suited to cover that case. Don't forget that RFC723x aim at describing
> what *is* deployed and how to best interoperate.

Yes, sure, but then it helps to more than prescribe behavior: describing
what deployed implementations do is quite helpful.

Suppose there are proxies that behave in conflicting ways, then that
would mean that clients would need to be configurable as to what they do
with 2xx CONNECT responses.  E.g., one kind of proxy might send policy
information in the 2xx CONNECT response body, while another might send
application data -- the client couldn't tell which behavior the proxy is
using without response headers to tell it, or out-of-band configuration.

ISTM that this section of the RFC needs work, and I may write up an
erratum about it.

Nico
--

Received on Wednesday, 29 April 2015 16:41:18 UTC