Re: Problems with Limecast Server

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 -