137339 - want way to hand URL to helper apps without downloading whole document first (for streaming)

Status: NEW

(Firefox :: File Handling, enhancement)

Description

[Jamie Zawinski]

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.)

Comment 1

[Boris Zbarsky [:bzbarsky]]

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....

Comment 2

[John Levon]

bug 54217 related ?

Comment 3

[Bill Law]

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?

Comment 4

[Boris Zbarsky [:bzbarsky]]

I don't have IE available, unfortunately.  :(  Jamie?  Do you?

Comment 5

[Jamie Zawinski]

> Jamie?  Do you?

You're funny!

Comment 6

[timeless]

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

Comment 7

[Jamie Zawinski]

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.

Comment 8

[Waheed Islam]

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.

Comment 9

[Boris Zbarsky [:bzbarsky]]

> 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.

Comment 10

[Andreas Kunz]

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.)

Comment 11

[Christian Franck]

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.

Comment 12

[(Anonymous)]

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

Comment 13

[Bastien Nocera]

> > 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