cURL / Mailing Lists / curl-library / Single Mail


Re: bug #39 -- let's fix it

From: Nico Williams <>
Date: Mon, 27 Apr 2015 20:36:33 -0500

On Mon, Apr 27, 2015 at 05:26:53PM -0500, Nico Williams wrote:
> The fix to apply should be trimmed to just this:
> index f3c54bd..94a384a 100644
> --- a/lib/http_proxy.c
> +++ b/lib/http_proxy.c
> @@ -269,8 +269,7 @@ CURLcode Curl_proxyCONNECT(struct connectdata *conn,
> break;
> default:
> DEBUGASSERT(ptr+BUFSIZE-nread <= data->state.buffer+BUFSIZE+1);
> - result = Curl_read(conn, tunnelsocket, ptr, BUFSIZE-nread,
> - &gotbytes);
> + result = Curl_read(conn, tunnelsocket, ptr, 1, &gotbytes);
> if(result==CURLE_AGAIN)
> continue; /* go loop yourself */
> else if(result)

This breaks tests like test206, which effectively send junk in the CONNECT

RFC7231 says this:

   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.

The junk sent in test206 is not sent with Content-Length, nor is it
chunked or anything. It is clear that data sent this way is
indistinguishable from data sent by the entity on the server-end of the
tunnel, so discarding it as libcurl does is clearly wrong and racy.

Some curl tests have proxies that violate the MUST NOT from RFC7231.

The curl client is in violation of the "MUST ignore" text.

A complete fix then starts with the patch I sent earlier, but requires
fixing various test cases, and also removing code to handle
Content-Length and Transfer-Encoding handling from Curl_proxyCONNECT().

At a minimum the tests need fixing, while removing the Content-Length
and Transfer-Encoding handling from Curl_proxyCONNECT() could wait for
another day.



List admin:
Received on 2015-04-28