Any thoughts, on how to handle this? I wish, squid would handle this case gracefully somehow.Its not HTTP; it doesn't really matter if its HTTP-like. Steven Wilton has some patches to Squid-2.6 which implement "full transparency" on non-HTTP looking data; perhaps you want to use those.
Sorry, i have to reply again.I took a look at Steven's patches. They look, as far as i understand, like they add support for non-HTTP data sent by the client. (Some client tries to reach a server on port 80, but the client sends some non-HTTP-request-like data).
This is not the case in my scenario.WinAMP, mplayer, and all these clients send proper HTTP-requests to Squid. And squid sends a proper HTTP-request to the Limecast server on port 80.
Yet, the reply of the Linecase server is NOT a HTTP 1.x response. So Squid gets confused and interpretates this as a HTTP 0.9 response. And somehow, the mp3-data get's terribly broken.
These stream-servers out there on the net send this "ICY 200 OK" response INSTEAD of the normal "HTTP/1.0 200 OK" response.
So i'm NOT looking for support of non-HTTP-requests (sent to squid by the client), but i'm looking for support of non-HTTP-replies (sent to squid by these non-HTTP-compliant servers)!
Any thoughts? Regards, Sven
signature.asc
Description: OpenPGP digital signature
