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 _______________________________________________ Xmms2-devel mailing list Xmms2-devel@lists.xmms.se http://lists.xmms.se/cgi-bin/mailman/listinfo/xmms2-devel
