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.0


So "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

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to