Consider an HTTP page that links to some mp3 files. If I click on a link, Mozilla downloads the whole mp3 file to a temp file, and several minutes later, it invokes "xmms /tmp/XXXX", and I hear audio. If, instead of downloading the data, it would have just invoked "xmms http://...XXX.mp3", then I would have heard audio immediately, because xmms can play streams. I can get this behavior by launching xmms by hand, and then dragging and dropping the URL links onto the xmms window; but that assumes that I have xmms running already, which I might not. I'm not sure what the best way to do this is, since you still need to contact the server to find the content-type -- perhaps you could start downloading the URL, and then once you know the content type, and see that you're supposed to just pass the URL to an external program, abort the download and let the external program start over? Way way back, we used to have a .mailcap extension that would let Netscape start external programs as a pipe, and stream the data to them on stdin -- I don't know if that's still supported, but even if it is, it doesn't help much, because xmms can't read from stdin. It wants either a filename or a URL. Web sites can side-step this problem by using .M3U or .PLS files, which are small documents that just contain indirect links to the real URLs -- Mozilla downloads the M3U, hands that to xmms, and xmms opens the HTTP URL that is inside -- but there are a lot of web sites out in the world that do not do it this way (e.g., if it's just a directory listing of files.)
See also bug 115041. I'll likely fix that eventually, but that would be a unix-only solution. Bill, do we want to make this work XP? I'm surprised this has not come up on the windows side so far....
bug 54217 related ?
Probably we need another attribute for the helper app entry indicating that we need to pass the URL vs. pass a temp file with the content. I think we should address this issue in the course of addressing bug 115041. Question: how does IE handle this?
I don't have IE available, unfortunately. :( Jamie? Do you?
> Jamie? Do you? You're funny!
i thought bz has IE Solaris. but .. I thought that realplayer for windows had a way to specify that it wanted urls. But I don't have that installed. The reason I don't have it installed is that the installer doesn't work for me :-o
I imagine it's also easier for IE because they don't care about MIME, so they will just key off of the file extension in the URL without having to load the document to find the Content-Type header first.
in the case of .mp3 files, ie4 used to download the file upon click, then launch the associated app based on the extension. ie6 looks at the extension and if it recognises it, it suggests whether the user wants to play it using ie, if no, then it would open windows media player and start streaming the file. In the case of mozilla, if the file is not recognised (based on mozilla's helper application) we should open the default download dialog and ask the user what they want moz to do - this is what actually appears to happen on win32, should be the same for linux? ... 1. open the file using <app> 2. download file may not be relevant, but intresting... i just uploaded a jpg file to www.mrc-gprf.ac.uk/test.sdf .. and renamed extension to .sdf when going to this url, mozilla doesn't examine the header, it simply starts displaying [downloading] the file as if it was text. using both ie4 and ie6, they read the header then actually display the jpg image! using, 20020424 on win95.
> should be the same for linux? It should, and it is. There's a dialog that comes up that offers the options of "save" and "open with helper". > when going to this url, mozilla doesn't examine the header, You mean the HTTP header? Sure we do. It says the data is text/plain and we display it as such, per the HTTP spec. IE ignores the HTTP header and looks at the actual image data and guesses at the image type instead.... None of which is relevant to this bug.
This sounds like similar to bug 90501. (Although that other bug is all/all and here are Linux-only solutions discussed in connection with bug 115041. However, the initial description is about the same.)
Besides of multimedia streaming, the fixing of this bug seems very important to me in the context of WEBDAV enabled applications (like OpenOffice). The idea is to have browser-based content (document) management systems, where the documents are not stored on a 'simple' fileserver, but on a webserver with webdav. The user logs into his intranet, navigates to the document, clicks on it to open it in OpenOffice (or any other application supporting webdav). Then he can work on the document and finally save it right back to the server. This is only possible when the helper application has the URL, since otherwise the user can only save back his changes to the local temp file, which of course has not the desired effect. So, to me this url feature is a key feature, since it is the missing link between the browser and the (webdav) applications.
13 years ago
as workaround you can use the 'Download With' extension https://addons.update.mozilla.org/extensions/moreinfo.php?application=firefox&category=Download%20Tools&numpg=10&id=27
> > should be the same for linux? > > It should, and it is. There's a dialog that comes up that offers the options of > "save" and "open with helper". Similarly to bug 115041 (which is about mailcap using '%u'), the desktop file spec has "%u" and "%U" to say they handle URLs. See http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s06.html