GNOME Bugzilla – Bug 502325
Shoutcast support.
Last modified: 2008-01-16 22:00:52 UTC
In a fit of severe brain damage, the Shoutcast developers decided to break the HTTP protocol by returning "ICY" instead of "HTTP/1.x" in the HTTP response header. While it would be nice to fix this and inflict some physical pain on whoever is responsible for that screw-up, it is admittedly less effort to simply support this and get working Icecast/Shoutcast support in GStreamer with the libsoup HTTP source.
Created attachment 100530 [details] [review] Fix.
*** Bug 396081 has been marked as a duplicate of this bug. ***
Funny, I was looking at this the other day. I decided that my ideal fix for it would be to add I/O filters that let you rewrite the data stream after libsoup reads it but before it parses it (and on the write side, after it serializes the data, but before it writes it to the socket). That would allow us to deal with this, and also various other sorts of broken HTTP implementations, while keeping libsoup's parsers clean. But that's a long way away. Your patch assumes Shoutcast servers are HTTP/1.1, as opposed to HTTP/1.0. Is that true? I couldn't find any evidence either way unfortunately. I guess the big difference would be if they expect the connection to stay alive after a request by default or not, but since shoutcast uses message-terminated-by- closing-the-stream semantics anyway, there's no real way to tell... Have you found any better documentation than http://forums.radiotoolbox.com/viewtopic.php?t=74 ? Also, this patch wouldn't help with implementing the server side of Shoutcast. Another possibility would be to add a new value to SoupHttpVersion rather than just translating "ICY" to SOUP_HTTP_1_1, and then a SoupServer that wanted to send back a Shoutcast response would just do soup_message_set_http_version(msg, SOUP_HTTP_ICY);
It had indeed just been pointed out to me that Shoutcast does not behave like HTTP/1.1, and that 1.0 is a better choice. I had not actually bothered to check documentation; I just fixed it until it worked... I also didn't consider the server-side case. If you want to do it all nice and OO, perhaps you could identify the protocol differences and have a HTTP/1.0, HTTP/1.1 and Shoutcast subclass to the client or server object, allowing the application to implement a custom subclass... ;-)
fixed in svn