RE: MP3DefaultOperation

Um yeah....

I have plenty of comments about this header... I know it well! ;)

Content-disposition: It was part of the http1.1 spec, and not all browsers
treat it the same. IE4 does them different than IE5, and IE5 does it
different than IE6. Netscape and Mozila seem to be consistent with them, but
there are other browsers who do their own thing with them.

All content-disposition does is tell the browser, rather force the browser,
to give the user an option to dispose of the data how they wish. This has
everything to do with the situation where the browser doesn't know the
filetype (aka mime) of the file your asking for. 

Honestly the situation has more to do with correctly configuring Netscape on
Microsoft. A special case for Microsoft users is that all files, and file
types, are bound by the notion of having '.foo' file extensions. For
example, Installing WinAMP on Windows: Winamp takes control of the
file-types .pls, .m3u, .mp3, and makes a change in the system mime-table to
reflect this change. You can see them by opening any 'Windows Explorer'
windows, then going under 'Tools', and clicking on 'Folder Options'. If you
look at the 'File Types' tab, you can see what WinAMP controls, and how it
works. This is where Internet Explorer knows how to 'dispose' of the
audio/mpeg (or whatever mime it is?) to the WinAMP.

On Unix there is no notion of a '.foo' file extension, so every thing falls
back on mime-type headers, but Netscape kinda makes-up for that in it own
way. Actually this is true for Microsoft users of Netscape too. You have to
mess with the helper-app setting under the Netscape preferences. A really
good hint for Microsoft users is to take a glimpse of the system mime-table
(from the paragraph above), and copy some of that stuff down for use in the
Netscape settings. For Unix users, I suggest using the XMMS website for
pointers. They have this issue listed in the XMMS documentation, section
7.1: 
http://www.xmms.org/documentation.html

7.1. Shoutcast support
---------------------

To make Netscape use XMMS on http://www.shoutcast.com you just have to load
up
Netscape and choose view/preferences/Navigator/applications add a new
handler
set mimetype: audio/x-scpls
set application: xmms %s
hit the OK button and off you go!

And for http://www.mp3.com

Set mimetype: audio/x-mpegurl
Set suffix: m3u
Set application: xmms %s


I have seen situations where 'content-disposition' is assumed. I have seen
developers use the header on browsers that simply don't support it, and had
unexpected results. Most of the time when a browser doesn't support a header
they simply ignore the header, do nothing, or force a download anyways.
Other times I have seen some browsers really freak-out!

Generally speaking, if you have to use the content-disposition header, you
might have a broken browser! IE5.5 is a broken browser, and if you have that
browser. That version doesn't handle the content-disposition header
correctly, and Microsoft created like 4 different patches to address the
issue. Each patch has not correctly solved the issue. Microsoft's official
stance on the matter is to use IE6. Its funny when you see a Microsoft
browser prompt the user to save/open a file twice, in a row, just because
the content-disposition header is implied, and you sent one anyways. IE's
behavior is to just force the disposition twice.... Truly hilarious!

This all falls back on mime types. Why? Because Mod_mp3 doesn't send a file
name, with the implied '.foo' file extension thingy. It only sends a
Mime-type header, and possibly the content-disposition header. I'm talking
about mod_mp3 in the op=play mode. Mod_mp3 is going to send 'audio/mpeg', or
'audio/x-mpeg', or something like that (look at the source), and the
user-agent is going to have to either know how to dispose of the mime-type
(Netscape), or have the ability to look at the main system mime tables (IE).

Using the content-disposition is not going to magically tell Netscape how to
make XMMS, or WinAMP open the data, just interrupt and force a disposition
(aka 'save as', or 'open with'). This is not going to be the same case if
you are going to use the content-disposition headers for a playlist. I have
seen some really weird stuff going on with the way .m3u playlist are treated
on IE when content-disposition is not used, where .pls playlist's are not
effected. The problem is that Microsoft expects a real file (aka file
extension) to be present, and doesn't anticipate stream/downloading an m3u
file based on mime-type alone. In that one case I would say
content-disposition is good. Since mod_mp3 DOES NOT represent itself as a
.m3u file on the url, I have seen some of these problems arise. Mod_mp3
represents itself on the url as op=mu3, not a .m3u file. A perfect situation
for the usage of content-disposition. Op=play is NOT a good place for
content disposition, unless you really want to force a download prompt on
the user. It better to simply have your browser correctly handle the
mime-type. Ampache, and MUMMI both get around the playlist problem by using
special php files that are playlist.pls, and playlist.m3u (but really they
are just php script). They appear correctly on the url. Shoutcast also
recognizes this issue, and provides a special 'listen.pls', that you can use
on the url.

For the curious, content-disposition was created so you can do cool stuff.
One example I can list is in MUMMI where I use a download.php file to
deliver mp3, ogg, or whatever to my local browser. I use the mime-type
header to tell the user-agent that the data is audio/mpeg (or ogg), the next
header I send is the content-disposition header to use a specified filename
rather than save the file as 'download.php'. This way my download php can
replace its own name for the file to be download, with its' own name, and
force the browser to save/download:

header("Content-Type: audio/mpeg");
header("Content-Disposition: attachment; filename=$disp_name");
readfile("$p");

Naturally, on some browsers, this will still save as 'download.php' simply
because content-disposion is not supported.

Sorry for the long-winded reply, this is a subject I can ramble on, and on,
and on about. ;)

Make it default, sure... Just make it so I can disable it. Thanks!

-Jon Disnard
http://www.audiodevil.org








-----Original Message-----
From: Brian Aker [mailto:[email protected]] 
Sent: Saturday, June 08, 2002 03:12
To: [email protected]
Cc: Tim Wunder
Subject: Re: [Mod_mp3] MP3DefaultOperation


On Sat, 2002-06-08 at 12:42, Bruce M. Walker wrote:
> WinAmp used with Netscape or Mozilla doesn't work with mod_mp3 as-is 
> and needs this option.  The option used to be enabled by default, but 
> was disabled for reasons unknown.
There was some issue this was causing and I am not sure what it was anymore.
I know that Jon had some thoughts on it at the time (which is why I made it
optional).

Unless someone come up with a reason for it to not be default I think I will
change it to being default.
	-Brian
-- 
_______________________________________________________
Brian "Krow" Aker, [email protected] 
Slashdot Senior Developer
Seattle, Washington
http://tangent.org/~brian/
http://askbrian.org/ _______________________________________________________
You can't grep a dead tree.

_______________________________________________
Mod_mp3 mailing list
[email protected] http://lists.tangent.org/mailman/listinfo/mod_mp3