Password extends into headers with BUTT shoutcast compatible source

Hi, I've found a bug in 2.4.3 (which if I understand correctly is the same as 2.4.2 for Linux). Its a fairly minor one and is in part caused by the Source. If you use BUTT (https://sourceforge.net/projects/butt/) to broadcast and setup an Icecast connection it works find. However if you set it up as a shoutcast connection and send to a shoutcast compatible port on icecast it fails. Now the obvious question is why we'd use the "old" way of doing things. The answer is we are moving from shoutcast to icecast and a lot of our broadcasters still have the shoutcast settings and I'll like it to "just work" for them.

The problem is BUTT mixes its line endings, after the password there is just a /n but in the header lines it uses /r/n In _handle_shoutcast_compatible in connection.c there is some code

        /* Get rid of trailing \r\n or \n after password */
        ptr = strstr (client->refbuf->data, "\r\r\n");
        if (ptr)
            headers = ptr+3;
        else
        {
            ptr = strstr (client->refbuf->data, "\r\n");
            if (ptr)
                headers = ptr+2;
            else
            {
                ptr = strstr (client->refbuf->data, "\n");
                if (ptr)
                    headers = ptr+1;
            }
        }

Which unfortunately matches on the \r\n on the header, and misses the \n on the end of the password. So it uses the password a \n and the first line of the headers as the password, which fails and it rejects the connection.

For my purposes I've fix it by changing the code to:

        /* Get rid of trailing \r\n or \n after password */
        ptr = strstr (client->refbuf->data, "\n");
        if (ptr)
        {
                headers = ptr+1;
                while ( ( ptr > client->refbuf->data ) && ( ptr[-1]=='\r' ) )
                {
                        ptr--;
                }
        }

So it finds the first \n and backtracks to remove any \r's

Obviously this is an edge case, in general people using BUTT will use icecast native connections, and most source client don't use mixed line endings. But I think my fixed version is probably more efficient on average anyway, so I think it should be safe to add.

I was going to try and submit a patch, but it looks like the code has moved on since the last version released, though even that didn't seem to use the latest changes at the time. So I'm not sure what is happening in that area. I'll leave this here and if its of any use then please include it. If you can shed more light on the evolution of the file and its worth it I can clone the latest version and test and if necessary make a patch for it.

Regards Gary