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
