Well, the problem is now well-understood. Can you think of any way to identify that the request is going to result in a non-HTTP response?
There's a couple of possibilities that I can think of - either add support to squid to handle this, or add in logic to Squid to determine the request needs to be passed through, and possibly figure out a way to glue the connections together into a tunnel. Patches are welcome. :) Adrian On Sat, May 17, 2008, Sven K?hler wrote: > >>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 > -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -
