cURL / Mailing Lists / curl-library / Single Mail

curl-library

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

From: Nico Williams <nico_at_cryptonector.com>
Date: Tue, 28 Apr 2015 10:00:12 -0500

On Tue, Apr 28, 2015 at 09:23:39AM +0200, Daniel Stenberg wrote:
> On Mon, 27 Apr 2015, Nico Williams wrote:
> >This breaks tests like test206, which effectively send junk in the
> >CONNECT response.
>
> Hopefully changing behavior _does_ break one or more tests. It only
> proves we actually verified the existing behavior. But changed
> behavior would then also require changed and updated test cases
> accordingly...

Right.

> >At a minimum the tests need fixing, while removing the
> >Content-Length and Transfer-Encoding handling from
> >Curl_proxyCONNECT() could wait for another day.
>
> Let's remember this:
>
> A server MUST NOT send any Transfer-Encoding or Content-Length header
> fields in a 2xx (Successful) response to CONNECT.
>
> And let me emphasize the "2xx" part there. A CONNECT response can be
> a lot more than just 2xx responses and both Transfer-Encoding or
> Content-Length headers are frequently used in such responses. We
> cannot remove the support for them without breaking numerous
> applications.

Ah, yes, so we need to only tweak the handling of 2xx responses.

> We can make sure to bail out nicely and properly though if they
> occur in 2xx responses. And add tests that verify that!

RFC7231 says the client "MUST ignore", not "MUST fail" or something like
that. I'm not sure why that would be.

In any case, the tests currently have the "proxy" send junk that is not
accounted for via Content-Length or Transfer-Encoding.

Nico

-- 
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html
Received on 2015-04-28