On Mon, 30 Apr 2007, Tobias Rundström wrote:

> In XMMS2 we use libCURL for HTTP streaming (ice/shout cast and friends).
> Recently Apple issued a security fix for OSX that included a new version of
> libCURL (7.16.1) and at the same time debian sid shipped 7.16.2 as default.
> This broke streaming for our users.

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.

> 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?

> 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?

> And in the mean-time we would like to know if there is a workaround to this
> issue since we probably can't control what versions of libCURL is shipped
> with OSX.

I can't think of any work-around that doesn't involve changing the server,
using a proxy or patching the source code, no.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html