109897 - helper applications are not resolved properly when getting file from CGI script

Status: VERIFIED FIXED

(Core Graveyard :: File Handling, defect, P1)

Description

[wazow]

Build: 2001101202

I have a problem with my webbased web service (I cannot give you url to my
private mailbox I am afraid... :). But whenever an attachment appears it is
linked to some CGI script as on the excpert below:

<a HREF="/setup/brak_nazwy?readmail=138:2">filename</a>

The cgi-script uploads the file as application/octet-stream to the browser. This
makes the browser invoke the helper application for binary files regardless the
real file type. Even if the name of the file contains a proper extension (.HTML,
.pdf .jpeg or whatever). Each time I click on the attachment I have to specify
the helper by hand (even for html, jpeg etc - files which would be normally
handled in mozilla window itslef).

I do not know if it is a bug or rather a bad website, but I can imagine that the
provider (http://www.home.pl) does not like to make proper attachment
categorization in his upload script. This job is normally done by browsers!

Workaround? : I specified acrobat reader as the helperr for Octet-Stream since I
get heaps of PDFs these days. Now I only have to specify helper manually if sthg
else arrives. Not really a workaround.

Another (connected) thing is that even when I specified an automatic handler for
octet-stream (with don't ask me for the action again ticked) I am still being
asked what to do with the file being downloaded.


andrzej

Comment 1

[Boris Zbarsky [:bzbarsky]]

> I can imagine that the provider (http://www.home.pl) does not like to make 
> proper attachment categorization in his upload script. This job is normally
> done by browsers!

Wrong.  This is completely and utterly the server's responsibility.  The only
reason browsers do it is to work around problematic servers

That said, a few things:

1)  Do you have /etc/mailcap and /etc/mime.types?  Those are the system files
    that hold mime information.  If you have them, a recent Mozilla build will
    pick up info in these files.
2)  Please read the 0.9.4 release notes for information on how to set your
    helper app preferences to pick up ~/.mime.types and ~/.mailcap.
3)  Define helper applications for those extensions, and once bug 109236 is
    fixed this will get a little better.

There is an interesting problem here, though.  The first thing we do is check
for the content type.  If your system defines extensions for
application/octet-stream (as most Linux systems do in /etc/mime.types), we treat
that as having mime info that we can use.  So we never do an extension lookup. 
This is not so great in this case and in many others.  Attaching a patch to fix
that.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch to only match if we have a handler

Comment 3

[wazow]

> This is completely and utterly the server's responsibility.  The only
> reason browsers do it is to work around problematic servers

Shall I submit it as Tech evangelism then ?


> There is an interesting problem here, though.  The first thing we do is check
> for the content type.  If your system defines extensions for
> application/octet-stream (as most Linux systems do in /etc/mime.types), we 
> treat that as having mime info that we can use.  So we never do an extension >
lookup. This is not so great in this case and in many others.  

I do not completely understand. I have my mailcap and mime.types files 
specified now. There is an entry for octet-stream in /etc/mime.types but it does
not specify the bloody PDF extension on its list. I guess that what you patched
now is that mozilla will check the extension in future.

Another question is why does the browser ask me for action on this file EVEN if
I have a helper for octet-stream defined in mozilla setup. If I click do not ask
me again it will ask me next time anyway.

Comment 4

[Boris Zbarsky [:bzbarsky]]

No, I wouldn't bother evangelizing this...

> There is an entry for octet-stream in /etc/mime.types but it does
> not specify the bloody PDF extension on its list.

Right.  And if it did, that would not help, since we do helper lookups by type.
 So the thing that needs to happen is that we need to map .pdf to
application/pdf in this case, not to application/octet-stream.  What I patched
is that we will look for a helper for the extension if there is none for the
type even if it's a "known" type.  This should fix your problem.

> Another question is why does the browser ask me for action on this file EVEN
> if I have a helper for octet-stream defined in mozilla setup.

That I do not know, but I believe that's filed already...

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 57598 [details] [diff] [review]
Patch to only match if we have a handler

r=biesi

Comment 6

[rpotts (gone)]

Comment on attachment 57598 [details] [diff] [review]
Patch to only match if we have a handler

sr=[e-mail]

Comment 7

[Boris Zbarsky [:bzbarsky]]

checked in

Comment 8

[sairuh (rarely reading bugmail)]

what would be a good test for verifying this? or, would Andrzej be able to test
this himself with a recent build?

Comment 9

[Boris Zbarsky [:bzbarsky]]

Hmm..  A good test would be a server that sends pdf content with a "pdf"
extension (or no extension) and an application/octet-stream content type.  To
test one would need a Linux system with an /etc/mime.types file that includes an
entry for "application/octet-stream" (most do).

And yes, Andrzej should be able to test this... it should certainly help his pdf
problems.  Any build from 2001-11-28 or later would do.  :)

Comment 10

[wazow]

I think I can test it.  I can do it know with my email provider (before they
upgrade the software - as they priomised me to do soon :). If I have time I can
also test it on my local apache and let you know.

Do you mean that it's in nightly build already ? The other thing is that I do
not really know how to proceed after I am done with the test (how to report it ?).

Comment 11

[wazow]

I made the test with Build ID: 2001112821 and my webmail client. Just in case
they upgraded the client I checked with wget that the website scripts still send
anything as application/octet-stream (and they do).

It's better now: pdf documents are handled properly when being sent as
application octet-stream (there is an entry in my mime.types file for
octet-stream but without pdf on the list). This seems to be the expected
behaviour, but...

the hadler application called is the one which is defined for application/pdf in
global mailcap file - not the one which is defined in
preferences/helper-applications. I am sure of this bcs conincidentally this is a
different application (xpdf vs acroread). Consequently the files having handlers
defined in mailcap files are being handled decently while those having a helper
application defined within mozilla still ask for action. Why? Shouldn't local
mozilla setting superseed global mailcap file? 

Actually I do not even understand why we need this double layer
(mailcap/preferences) scheme?

Comment 12

[Boris Zbarsky [:bzbarsky]]

Andrzej, what you're seeing now is bug 109236 (has a patch, has review, needs
super-review).  Since we're now using the extension instead of the type to
handle those files, we need to look up by extension in preferences.

The reason for the double layer is twofold:

1) NS4 uses ~/.mailcap for its helpers, so this allows us to effectively migrate
   any helpers it sets.  ~/.mailcap overrides the global mailcap, but needs to
   be pointed to explicitly in the preferences with an absolute path.  :(  See
   the 0.9.4 release notes.

2) mailcap/mime.types is the closest thing to a standard way on Unix to define
   helper apps for some types and then have _all_ mime-aware programs use those
   helpers.  It's the equivalent of Internet Config on Mac or the system mime
   registry on Windows.

In any case, helper app preferences override this global configuration, so once
bug 109236 is fixed you should see completely correct behavior here.

Marking verified per Andrzej's comment.  The fix does what it's supposed to. 
Andrzej, thanks for testing it (and for doing a good thorough job of checking
what the server sends!).