Re: Clarification for RFC7231 CONNECT (section 4.3.6)

One other thing could use clarification.

We find many browsers do not show the content associated with a 403 
response to CONNECT, and instead show some generic "unable to connect" 
page which is most unhelpful (even when the content is over the size 
threshold for showing "friendly" aka unfriendly errors).  Is there some 
way we can make this more forceful?

Adrien

------ Original Message ------
From: "Zhong Yu" <zhong.j.yu@gmail.com>
To: "Nico Williams" <nico@cryptonector.com>
Cc: "HTTP Working Group" <ietf-http-wg@w3.org>
Sent: 30/04/2015 3:37:55 a.m.
Subject: 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 21:48:52 UTC