Playing the following URL makes fb2k lock up very badly: http://slashdot.org/?play=test.flac

I believe the actual content is unimportant. Only the .flac ending and the HTTP status code 200 (success). The following URL returns code 404 and is handled well: http://google.com/index.php?play=test.flac

Thanks, fixed. FLAC library seems to be unable to return from FLAC__stream_decoder_process_single() function on invalid data.

There is a general problem with the http_reader. What makes you think http://slashdot.org/?play=test.flac is a FLAC file?

The url returns content-type: text/html and the first 4 chars are "<!DO". If it was a FLAC file the content-type would be audio/x-flac and the first 4 chars would be "fLaC".

You can't really determine the file type based on the url.

Testing only filename (URI) and content-type is easier/quicker than testing file contents for "magic numbers". You would have to open (and sometimes at least partially download from Internet, or network shares) file before you can even tell if any plugin can play it...

And it works good in most cases, except for trying to play mp3 renamed to *.ogg or trying to play html stream from url ending with .flac (etc.). In such cases noone can really expect that player would try to play something (and it does not).

Checking the content-type should be enough - that is why it's there.

I think correct behaviour (according to http RFC2616) would be to choose plug-in from specific content types like: audio/x-flac, audio/mpeg, application/x-ogg, and audio/x-wave.

If the general binary application/octet-stream is returned, plug-in can decided from url, and text/* should never be played.

Mime type is checked first and extension is used only if no match is found. Being strict and only playing proper mime types would be nice but unfortunately people usually don't bother configuring servers properly.