On Tue, Apr 28, 2015 at 08:33:32AM -0700, mm.w wrote:
> Hello , Nicolas mainly hypothetically an attacker could take avantage
> of it and inject ; the problem with being strict [which should be the

First, a proxy can manipulate the application protocol traffic tunneled
over CONNECT.

Secondly, if you're not using TLS between the client and the proxy, and
TLS or similar between the either the client or the proxy and the target
of the CONNECT, then you have all the security problems that one can
expect.

Neither bug #39 nor the RFC7231 text I quoted introduce new security
problems.

> way] ; you are absolutely right on this point ; regrettably ; the
> reality is quite different: I know many servers (used by a lot of
> folks) that are still 1.0/1.1-ish meaning they are "dirty-hybrids" ;
> that's the wildness of internet ;

Can you be more specific? What do 2xx responses to CONNECTs from such
servers look like? Do they carry response bodies? Are such response
bodies denoted with Content-Length: and/or Transfer-Encoding:?

How can any CONNECT 2xx response bodies not accounted for in
Content-Length: and/or Transfer-Encoding: be handled correctly without
knowing their length a priori or in some other way (maybe they are
self-delimited?)?

Can you name any such proxies? Are they still supported, for any value
of "supported"?

Should we add a new CURLOPT for indicating that a proxy misbehaves?

What should the sense of any such new CURLOPT be?

Sorry for all the questions. They are not rethorical. If fixing bug
#39 will break anything, it would help to know what.

Nico

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