Re: Clarification for RFC7231 CONNECT (section 4.3.6)

I've also seen clients send bodies on CONNECT requests...

It's not clear what is supposed to happen, but IME if you pass it 
through, then things don't work, so currently we silently swallow it.

Adrien


------ Original Message ------
From: "Willy Tarreau" <w@1wt.eu>
To: "Nico Williams" <nico@cryptonector.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Sent: 29/04/2015 5:01:20 p.m.
Subject: Re: Clarification for RFC7231 CONNECT (section 4.3.6)

>On Tue, Apr 28, 2015 at 03:38:58PM -0500, Nico Williams 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.
>
>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
>suited to cover that case. Don't forget that RFC723x aim at describing
>what *is* deployed and how to best interoperate.
>
>Regards,
>Willy
>
>

Received on Wednesday, 29 April 2015 05:11:06 UTC