Hello,

> If nothing else, I guess this will teach you to test run recent libcurls
> more
> often and carefully! :-O After all, this change was done in november last
> year without much complaints or anything.

Hehe, I guess my lesson is learned!

> 7.16.1 introduces a check for Content-Encoding and Content-Length. If
> these
> > headers are not included in the headers the connection will be closed
> > instead of starting to read the payload.
>
> The way I read RFC2616, that kind of reply is not a legal HTTP response. I
> understand this is not what you're saying, but are you saying I do the
> wrong
> interpretation?

No you are correct. I honestly don't care what the specs say :-) (or I do, I
like specs, they are great and follow them should be priority), but the real
world is what concerns me. And I guess icecast / shoutcast should not be
counted as HTTP RFC compliant.

> We suggest that this test should be optional (default TRUE works just
> fine).
>
> It works just fine for you, sure since that was how libcurl did it before.
> The
> problem for me is that it isn't then following the RFC and thus libcurl
> doesn't behave properly when a "legal" HTTP response comes with no such
> headers.
>
> I would instead suggest that we work on a fix that detects HTTP version or
> something, and do this check based on that since I'm referring to the HTTP
> 1.1
> spec and your streams don't seem to adhere to that? Aren't you even using
> HTTP200ALIASES to match the response?

Yes, both ways work for me. The later solution is of course more flexible if
we want to use libCURL for something else later. We are using HTTP200ALIASES
for ICY 200 which is the response from the server.

I will add 7.16.1 and 7.16.2 to a blacklist for our plugin for the time
being. Any idea when you can introduce this change, is it something you need
help with?

-- Tobias
Received on 2007-04-30