274665 - inconsistent mime type handling behaviour: local files vs http files

Status: RESOLVED WONTFIX

(Firefox :: Shell Integration, defect)

Description

[gustavo]

Given:

1) a local copy of a file
2) a remotely accessible copy of that file on a http server which doesn't know
its mimetype (sends text/plain)
3) a customized mimeTypes.rdf file

Firefox will show an different behaviour on handling the file depending on where
it comes from:

i) if the file comes from the local file system, Firefox will honor the
association defined on mimeTypes.rdf for that kind of file (in this case
kaffeine). This behaviour is right.
ii) if the file comes from the http server, Firefox will look for a "default"
application (in this case Totem), * ignoring the setting on mimeTypes.rdf *.
This behaviour is wrong.

Since for both cases the mimeType is unknown "a priori" (assuming Firefox
understands that text/plain sent by the server is wrong) there should be a
consistent mime type discovery/handling process.

Example file:

http://people.login.com.pt/~gustavo/funny/video/Milk.asf

A mimeTypes.rdf generator for KDE:

http://login.com.pt/kmime2mozilla

Comment 1

[Bill Mason]

(In reply to comment #0)
> Since for both cases the mimeType is unknown "a priori" (assuming Firefox
> understands that text/plain sent by the server is wrong) there should be a
> consistent mime type discovery/handling process.

This is an invalid assumption.  The mime type sent by the server always takes
first precedence.  If it's sending text/plain, that's a server error that's up
to the server admin to fix.

Comment 2

[gustavo]

https://bugzilla.mozilla.org/show_bug.cgi?id=274665(In reply to comment #1)
> (In reply to comment #0)
> > Since for both cases the mimeType is unknown "a priori" (assuming Firefox
> > understands that text/plain sent by the server is wrong) there should be a
> > consistent mime type discovery/handling process.
> 
> This is an invalid assumption.  The mime type sent by the server always takes
> first precedence.  If it's sending text/plain, that's a server error that's up
> to the server admin to fix.

Theoretically yes, but in practice no. Firefox, doesn't show it as text, as
would do things were as you suggest. It tries to find the mime type, however in
a way which is not consistent with the local file handling.

See:

http://www.geeknewz.com/board/lofiversion/index.php/t2036.html
https://bugzilla.mozilla.org/show_bug.cgi?id=220807

Comment 3

[Mike Connor [:mconnor]]

Here's what's going on:

If the server sends a file as the apache default (text/plain, ISO-8859-1) then
we check to see if its a binary or ASCII file type.  If its ASCII, we display
inline, otherwise we handle it as application/octet-stream and allow it to be
downloaded (since there is no effective way to guess mimetype before we
download).  Any non-default config we'll respect the headers (i.e. if its
text/plain, UTF-8, we'll display it as UTF-8 text/plain, even if its a flash movie).

Before its downloaded, we have no way to know what the correct mimetype is,
short of IE-style guessing on extension.  So the only solution that's viable is
to allow the user to download it intact, and open it locally.  End of story.

Comment 4

[gustavo]

(In reply to comment #3)
> Here's what's going on:
> 
> If the server sends a file as the apache default (text/plain, ISO-8859-1) then
> we check to see if its a binary or ASCII file type.  If its ASCII, we display
> inline, otherwise we handle it as application/octet-stream and allow it to be
> downloaded (since there is no effective way to guess mimetype before we
> download).  Any non-default config we'll respect the headers (i.e. if its
> text/plain, UTF-8, we'll display it as UTF-8 text/plain, even if its a flash
movie).
> 
> Before its downloaded, we have no way to know what the correct mimetype is,
> short of IE-style guessing on extension.  So the only solution that's viable is
> to allow the user to download it intact, and open it locally.  End of story.

I apologize for disagreeing but the point is not "displaying inline" versus
"downloading" the problem is only which application to open the file with!

Do this:
 
  - click on http://people.login.com.pt/~gustavo/funny/video/Milk.asf
  - the server sends text/plain as the mimetype
  - Firefox opens a dialog box where you see "Microsoft WMV Video" as the
mimetype  and you can choose between:
     - saving the file
     - opening with "Totem"
   - choose save, the download begins and in the end you can select "open" from
the download manager (or chose open even without saving -> same result)
   - It will launch Totem (ignoring mimeTypes.rdf)
   - Now go to the "File" menu and choose "Open File"
   - Select the Milk.asf from where you saved it
   - The dialog box now let's you 
      - save the file
      - open with "Kaffeine"

See the difference now ?

There is an inconsistency in the way firefox handles the same file, depending
from where it comes ...

Yes, this is trigered by a wrong behaviour of the server, sending plain/text for
that file, but the bug is there .... no doubt about it....

Comment 5

[gustavo]

This was tested on Mandrake Linux 9.2 with Firefox 1.0, downloaded from
Mozilla.org and a customized imeTypes.rdf file.

Comment 6

[Mike Connor [:mconnor]]

we get the app to open local files with from the local mimeservice.  This is by
design and will not be changed.

Comment 7

[gustavo]

(In reply to comment #6)
> we get the app to open local files with from the local mimeservice.  This is by
> design and will not be changed.

I think I still haven't made things clear enough...

1) The behaviour is correct for local files (mimeTypes.rdf is honored as
expected) , no one asked that to be changed !

2) The behaviour seems not correct for remote files if the server sends
plain/text as the mimetype, and firefox detects that it isn't text after all 

Why can't the handling for local files, which works well, be used for the latter
case ?

This would both, resolve the problem, and remove "duplicate" code...

-> the bug is with "remote non-ascii files which are erroneusly reported as
plain/text" <-

Comment 8

[Mike Connor [:mconnor]]

If remote files are sent using an incorrect mime type, there isn't a reliable
way of knowing what the "right" mimetype is until its downloaded.  If the file
is local, the OS tells us the correct mimetype.  If the file is remote, its an
unknown quantity unless the server gives us a proper mimetype.  If it doesn't,
and its binary, we'll download it and let you open it from your local disk.

That is as far as we are going to go in violation of the HTTP spec.  If that
doesn't suit you, fine, but I understand what you're saying, and I'm saying that
we're not going to fix it.  Period.

If you want to continue to argue this, please take it to email.

Comment 9

[Pedro Pessoa]

(In reply to comment #8)
> If remote files are sent using an incorrect mime type, there isn't a reliable
> way of knowing what the "right" mimetype is until its downloaded.  If the file
> is local, the OS tells us the correct mimetype.  If the file is remote, its an
> unknown quantity unless the server gives us a proper mimetype.  If it doesn't,
> and its binary, we'll download it and let you open it from your local disk.

Perhaps it might be usefull for future reference understanding why does Firefox
identify the file as "Microsoft WMV Video" when the server sends text/plain.
This seems to be a little more that just application/octet-stream. 
What's going on for this to happen? This seems to be the core of your discussion.

Comment 10

[gustavo]

Attachment: opening a remote file

Comment 11

[gustavo]

Attachment: opening the same file locally

Comment 12

[gustavo]

One can see from the attachments that the same file is in both cases identified
as  "MS ASF Video", but different applications are offered.


 Server sends the wrong mime type 
 Firefox guesses the mime type correctly
 Firefox chooses the wrong application

Is this really not a bug ?

Comment 13

[Mike Connor [:mconnor]]

Using FC3 without generating any sort of arbitrary mimetypes file identifies
this as a BIN file.  All that I'm getting from the server is text/plain, so I'm
not sure how you're getting it as MS ASF.  From this end on a stock build, its
getting the http request as text/plain, sniffing for binary content, and
handling as application/octet-stream.  I'm not sure where you're getting that MS
ASF from, unless your mimetypes.rdf has some sort of custom entry doing this. 
Even saving from the server doesn't give me any other options than save to disk.

Comment 14

[gustavo]

Attachment: opening the remote file on windows 2000 / Firefox 1.0 stock

There is what happens on windows 2000, with an unmodified Firefox 1.0

Comment 15

[gustavo]

>  I'm not sure where you're getting that MS
> ASF from, unless your mimetypes.rdf has some sort of custom entry doing this. 
> Even saving from the server doesn't give me any other options than save to disk.

I just tried from a clean profile and I still get MS ASF and Totem as the
default application. This is not related to a mimetypes.rdf change.

I wonder why FF behaves differently on different linux distributions.

Comment 16

[timeless]

mozilla honors things like /etc/mailcap and gconf. linux distros tend to vary
wrt what's set therein.

Comment 17

[gustavo]

(In reply to comment #16)
> mozilla honors things like /etc/mailcap and gconf. linux distros tend to vary
> wrt what's set therein.

Interesting... I allways suspected the Totem setting was coming from gconf, but
wasn't sure.

So, the only remaining problem is why mimeTypes.rdf is forgotten in this case.

Comment 18

[Mike Connor [:mconnor]]

because the mimetype is text/plain, perhaps?

Comment 19

[Celso Pinto]

(In reply to comment #18)
> because the mimetype is text/plain, perhaps?

I've been watching this bug for a while now. Let's see if I can get this straight:
1) mimeTypes.rdf is considered if, and only, the mime-type sent by the server is
the correct one, otherwise the system's configuration is taken into account;
2) when opening a local file, mimeTypes.rdf always takes precedence in favour of
the system's own settings (e.g. gconf on Linux/Gnome);

If I get the picture right, somethings seems wrong with this configuration, because:

mimeTypes.rdf is a user configured preference. How would it feel if bash first
executed your ~/.bashrc before /etc/bashrc so that settings in /etc/bashrc
probably will undo your customized preferences? As such, it should take some
precedence. 

If Firefox is able to figure out the mime-type of the file when opening, it
should also be able to figure out the mime-type of that same file when it's
being downloaded. Since you already figure out that instead of a plain/text file
you have a binary, why not go a little further and try to find out what's the
correct mime-type as well?

AFAIK, when the webserver sends a text/plain content-type, Firefox already asks
the underlying system what's the default handler application for that particular
file (as one can see on the first attachment) so you've probably already figured
out what is it's mime-type. If not, please feel free to let us know how that
works, otherwise this really looks like a bug. Not a critical bug, but a bug
nonetheless.