Here's a question for those of you with an understanding of http protocol and how Internet Explorer deals with response headers.

I have a web app (mp3 server) I coded in PHP and runs on Apache that used to work splendidly with IE. It stopped working so splendidly since I updated my client with XP SP2, and whatever changes that makes to IE.

The server generates .m3u playlists and sends them along with the Content-Type: audio/x-mpegurl header. This worked well enough with IE before (and still does with most browsers) to kick off Winamp to deal with the playlist. Despite the request actually being a PHP script, the browser used the content-type header to properly identify the content of the file and send it on its merry way. Ever since installing SP2, this no longer works. It now prompts me to open or say a file playlist.php of Unkown File Type...it would seem that it doesn't care about the content-type header. Obviously if I select Save or Open, it treats it like a .php file on my system and not a playlist.

So I decided to take a look at the built-in webserver in Hijack to see how Mark's implementation of streaming playlists worked any better. It does. It occurs to me the Hijack server actually serves up the playlist as a file with a .m3u extension, as opposed to my server which is is a .php file. Setting the Content-Disposition: attachment; filename=whatever.m3u header isn't enough to convince IE w/ XPSP2 that the response really wants to be an audio playlist file either. To get the same effect as Hijack, I have to register the .m3u extension in the Apache configuration file with PHP so they get processed by the PHP engine, and then renaming my playlist.php file with a .m3u extension. Which I did, and it works. This is not the ideal solution, however, as I'd rather not have to register that extension with PHP....I'd rather convince IE somehow that it wants to treat the response based on the content-type header.

For a while I was looking at header responses from the servers because I thought maybe it had something to do with the different reactions of IE, but now I'm thinking it's just a matter of the file extension of the script on the server (meaning IE completely ignores content-type). Using Firefox and the livehttpheaders extension to watch the headers for the transation (since I don't have the functionality in IE) shows the following response headers....

With Empeg/Hijack
HTTP/1.x 200 OK
Connection: close
Content-Type: audio/x-mpegur

With Apache/PHP
HTTP/1.x 200 OK
Date: Fri, 13 Aug 2004 20:27:19 GMT
Server: Apache/1.3.31 (Win32) PHP/5.0.0
X-Powered-By: PHP/5.0.0
Connection: close
Transfer-Encoding: chunked
Content-Type: audio/x-mpegurl

Both servers respond with the appropriate Content-Type header, yet IE works only with the Hijack server and not Apache. I was particularly looking at the Transfer-Encoding as something most capable of causing the different behavior between the two servers, though I'm not thinking that's the problem.

Any thoughts?

You could try tricking it by adding a parameter to the end of the url that ends with .m3u....

http://myserver.com/playlist.php?dummy=blah.m3u

-Mike

At some point, I remember Mark faking it out by including extra URL info unused by the server to insert a ".m3u" ending, like "http://www.example.com/playlist.php?extension=playlist.m3u" or some such. Would that work here?

Still, sounds like an IE bug to me, not that that helps.

Yes, I have always used that trick for much the same reason Mark did, and that might be part of why I never had any trouble before SP2. I had playlist.php?fid=<fid>&ext=.m3u and that, in combination with the content-type header, has always worked well enough before. Post-SP2, though, neither of those things work with IE.

I've found another solution, though it doesn't really fix the problem (if there's a fix for the problem at all...it just might be new unavoidable IE behavior). Instead of making .m3u version of my PHP scripts and registering the .m3u extension to be parsed by PHP (which I didn't like), I decided to use mod_rewrite module in Apache to translate requests for <fid>.m3u to playlist.php?fid=<fid>. Works like a charm.

Stupid IE.

It seems that MIME-Types in Windows are stored in HKEY_CLASSES_ROOT\.m3u:Content Type. I don't know how that data might be used, but it's worth looking to see if something has changed there.

If you haven't yet, make sure you read this stuff. My interpretation of it is that the content-disposition=attachment thing bypasses a lot of the other checks. It will still trigger a prompt, but would then probably give the user the checkbox to not prompt for that type in the future.

The article specifies a bit of a different syntax for the header than that in your post, though. It also seems to be different than the RFC. It's probably a typo on MS's part, but it seems to say that the actual header name is "Content-Disposition=attachment:" with the rest as the value. So, the header you're looking to use would be "Content-Disposition=attachment: filename=whatever.m3u". You might want to try that to see if that works. If it does, and it's indeed a different syntax than the RFC, that would be a bug worth knowing about.

edit : fixed link
-l0ser