On Tue, Apr 28, 2015 at 03:23:14PM -0700, mm.w wrote:
> sorry you did not got what I said ; the both sentences where not separated
> ; if you get twice different Content-Length you can lie ; [...]

I admit to having difficulty parsing this.

> [...] ; yes some proxy
> servers returns a body ; they can even have non-standard values for
> Transfer-Encoding
> ;

Is this the reason that RFC7231 says the client should ignore
Content-Length and Transfer-Encoding?

Incidentally, sometimes you just have to fix busted peers. Today I ran
into a server that rejects TLS 1.2 when used with SHA-256, and that
rejects connections from clients offering SSLv3 and higher. That server
just needs to be fixed; there are too many clients that would have to
workaround it, and we can't be boiling the oceans to interop with every
broken peer.

> Can you name any such proxies ?
>
> yes I could ; but would not be fair.

I'm inclined to fix bug #39 as proposed and let you -or anyone else who
needs it- contribute any CURLOPTs for falling back to the old behavior.

> At the end so yes they should be totally ignored ; but from time to time
> you can't.

This isn't useful. I'm asking for details that help me construct an
acceptable patch.

Please review the proposed patch (it's a one-liner) and the comments
about adding CURLOPTs for working around old, busted proxies.

The patch I will be sending (i.e., the patch I posted + changes to the
tests) will not have any CURLOPTs for restoring old behavior unless I'm
asked to.

Nico

-- 
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html