Re: [PATCH] Support ICY protocol (ICECast / ICEShout servers) in Squid-3

On Mon, 02 Nov 2009 22:22:41 +0100, Henrik Nordstrom wrote:
> mån 2009-11-02 klockan 00:43 +1300 skrev Amos Jeffries:
>> Since we have no central place where the headers are upgraded I've had

>> to skip porting the upgrade_http0.9 hack in Squid-2 and go straight to
>> accepting ICY protocol as an accepted response protocol and handling
it.
>
> What do you mean by "no central place"?

The parse+validate and upgrade are spread between HttpStatusLine, HttpMsg,
HttpReply, and client_side.

Testing the first-round patch, found the spot that was triggering the
header addition to 0.9 was done in two places, first by HttpReply on clone
and also by client_side on slow clients after each incomplete status line
parse attempt, then by HttpReply again after the client_side.

It's a little bit of a mess with correctly scoped code and incomplete
conversion of legacy code to such.

>
> Internally the headers should always be upgraded. To implement the
> squid-2 option then all that is needed is to detect when the header have
> been upgraded and then skip to send the header to the client.

This is merely accepting the ICY status line as a valid header. The
sub-headers are still operated as normal. The only crossover between the
protocols seems to be Content-Type which retains semantics. The upgrade is
still done and adds Via, Date, etc normally and seems not to effect the
client software.

I spent a rather enjoyable evening yesterday tested with Nullsoft WinAmp
and VLC against a number of radio and stream servers of various speeds and
networks.

>
> Just remember to not enable chunked encoding for the response..

Oh darn. Guilty.
AFAICT the keep-alive is automatically disabled because there is no
content-length set or possible.

>
>> Somewhat primitive for now. It's limited to parsing and regenerating
the
>> status line correctly, and
>
> Do this mean HTTP status lines is also properly preserved now?

Yes. And non-ICY status lines remains upgraded to HTTP/1.0 as required by
RFC.

>
>> skipping the HTTP/1.0 version override on
>> non-HTTP protocol replies.
>
> Right.
>
> What Squid-2 does is to add that header internally with HTTP/0.9 as
> version. The version is overridden anyway when the response is composed.

Aye. I read the patch many times ;)

Squid-3 stores them as:

 ICY-status
 ICY+HTTP-headers (new HTTP ones last due to appending)

Code which does upgrading on purely version numbers sees ICY as version
0.0. Any which gives trouble (such as chunked encoding) can be modified
slightly to check for sline.protocol==PROTO_HTTP as well as version.

>
>> Since it is on port 80 I've temporarily left the HTTP/1.1 required
>> header alterations happening. Some testing will be needed over the next

>> few days to ensure that the client software treats unknown headers
>> nicely. If needed overrides for those are easily done as well now.
>
> Or fall back on what squid-2 does.. internally upgrade but then skip
> sending an HTTP header out..

Testing succeeded. We don't need to play tricks with the other headers. It
hinges entirely on the first four bytes of the reply being "ICY "

Amos
Received on Mon Nov 02 2009 - 23:04:27 MST