Hello,i've got a transparent proxy setup for my LAN. I'm trying to listen to a radio-stream from a german radio station.
As far as i can tell, the server is Limecast 2.0.0. When the squid-Proxy is being used, the mp3-stream is terribly broken. Without squid inbetween and the server and my client (mplayer, audacious and the like) the stream works fine.
For testing, i used wget, which gives me the following output:# LANG=C wget -S "http://gffstream.ic.llnwd.net/stream/gffstream_stream_wdr_einslive_a" --2008-05-16 23:08:00-- http://gffstream.ic.llnwd.net/stream/gffstream_stream_wdr_einslive_a
Resolving gffstream.ic.llnwd.net... 87.248.198.199, 87.248.198.200 Connecting to gffstream.ic.llnwd.net|87.248.198.199|:80... connected. HTTP request sent, awaiting response... HTTP/1.0 200 OK Date: Fri, 16 May 2008 21:08:19 GMT X-Transformed-From: HTTP/0.9 X-Cache: MISS from myserver X-Cache-Lookup: MISS from myserver:8080 Proxy-Connection: close Length: unspecified Saving to: `gffstream_stream_wdr_einslive_a.3' [...]I also tried the same without squid in between, but wget gave no header output. Some FireFox-Plugin says, that the response sent by the server is simple the line "HTTP/1.x 200 OK".
Yet, with telnet, i see that the response is: ICY 200 OK Content-Type: audio/mpeg icy-br:128 icy-metadata:1 icy-name:Eins Live, Copyright: Westdeutscher Rundfunk 2006 icy-pub:1 icy-url:http://www.wdr.de Server: Limecast 2.0.0So "ICY 200 OK" is very much not HTTP - yet the protocol seems to be HTTP-like.
Any thoughts, on how to handle this? I wish, squid would handle this case gracefully somehow. Regards, Sven
signature.asc
Description: OpenPGP digital signature
