On Wed, Apr 29, 2015 at 09:35:55AM +0200, Daniel Stenberg wrote:
> On Tue, 28 Apr 2015, 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
> >; yes some proxy servers returns a body ; they can even have
> >non-standard values for Transfer-Encoding ;
>
> >Can you name any such proxies ?
> >
> >yes I could ; but would not be fair.
>
> I don't think it is very helpful to be this vague and argue that
> some proxies somewhere may in fact be violating the specs. We all
> know that everything exists somewhere.
>
> The question is if there is frequent or common enough use today for
> us to care going forward.

The thread on the HTTPbis list has been helpful. It seems that the
intended behavior is that any 2xx CONNECT response body should be
prepended to the server->client tunneled stream (that's the effect of
ignoring the response's Content-Length, at least for the identity
Transfer-Encoding).

Nothing was said about proxies that send junk not intended as part of
the application stream. I don't know if mm.w meant to describe proxies
that send application data in a 2xx CONNECT response body, or proxies
that send junk.

It seems then that libcurl has two bugs related to CONNECT:

 - bug #39;

 - not implementing the intended behavior as to 2xx CONNECT response
   bodies.

I believe these two bugs are completely independent of each other.

I doubt that the obvious fix for bug #39 will break anyone. If it does
we can add new CURLOPTs to handle that. I'd rather not introduce new
CURLOPTs that no one will need, and I'd rather find out that the simple
fix for bug #39 breaks some proxies than not find out about such proxies
at all. I got sidetracked so I don't have patches for the tests yet.

Nico

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