Re: How to deal with proxying shoutcast / ICY protocol

On Fri, Mar 11, 2011 at 01:05:00PM +1300, David Young wrote:
> Works as advertised, thank you :)
>
> One thing is now missing from my setup, and that's the ability to
> identify WHICH source IPs are accessing WHICH sites.
>
> Without haproxy, I'm able to do this with squid's access.log, and with
> "mode http", I'm able to see this in the haproxy logs.
>
> When I enable "mode tcp" though, to work around this silly shoutcast
> issue, I get source IPs _only_ in the haproxy.log, and my squid access
> log reports every request has having a source IP of my haproxy host.
>
> Any ideas?

Well, at this point, I think it would make sense to start thinking about the possibility to implement HTTP derivative protocols such as shoutcast and icap. We need to carefully study their specificities and their compatibility with HTTP so that we figure if we have to configure exclusive support for one or the other, or if we can dynamically adapt without taking risks nor opening security issues.

For this, we have to consider the following points :

• what does a normal shoutcast request look like
• what does a proxied shoutcast request look like
• do shoutcast servers accept HTTP/1.0 or 1.1 requests
• what does a shoutcast response look like
• can it be sent in response to a valid HTTP request, and what is the risk of wrong identification (eg: assume shoutcast instead of http or conversely)
• do shoutcast clients accept different responses
• do some proxies accept "hybrid" requests such as shoutcast requests with many standard HTTP headers

There are probably other points that will come after those ones, those are just a few thoughts. Maybe we'll figure a way to easily build a basic implementation, or maybe it will require some deeper work.

Willy Received on 2011/03/11 09:23