Re: [BUG] libCURL 7.16.1 and up breaks streaming.
Date: Wed, 02 May 2007 20:47:28 +0200
Daniel Stenberg wrote:
>> 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.
> My suggested patch is attached. It requires that you set
> CURLOPT_HTTP_VERSION to CURL_HTTP_VERSION_1_0 in addition to the
> CURLOPT_HTTP200ALIASES option.
This doesn't sound really optimal to me. We (xmms2) don't know if the
URL is an ICY-stream or a file normal HTTP server. If it is a normal
file we still want to use HTTP 1.1 to get all the goodies such as being
able to do seeking (which isn't implemented in our plugin currently, but
there is an out-of-tree patch for it).
Could it be changed so that if one of the HTTP200ALIASES is matching it
forces it to version 1.0?
I see that today it just sets it to what has been requested..
(data->set.httpversion==CURL_HTTP_VERSION_1_0)? 10 : 11;
It's kinda hard to say which version to use. What other uses than
shoutcast streams do this HTTP200ALIASES-thing have?
One could argue that the if user requested 1.1 the response should be
threated as 1.1 if the version couldn't be determined. On the other hand
when the version can't be determined it would be nice if the most
liberal parsing was used, 1.0 in this case. That would make our (and
anyone else that doesn't know a priori if they are connecting to a real
HTTP/1.1 server or one that sends an HTTP200ALIASES header) life easier.
Received on 2007-05-02