242743 - html file with ".com" suffix/extension incorrectly indicated as type application/octet-stream

Status: RESOLVED EXPIRED

(Core Graveyard :: File Handling, defect)

Description

[jon rekai]

User-Agent:       Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7b) Gecko/20040423
Build Identifier: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7b) Gecko/20040423

(HTML?) files with bin,com,exe suffix/extension are incorrectly indicated as
type application/octet-stream.  Instead of displaying the content as 1.6 and
earlier do, the "Opening..." dialog is presented, indicating the file is a
binary.  Maybe on MS platform this is an ok assumption...

This only occurs when the file is loaded from the local filesystem.  When
retrieved http and the correct content type is indicated, behavior is as expected.

?
http://lxr.mozilla.org/seamonkey/source/uriloader/exthandler/nsExternalHelperAppService.cpp#377


(affects 1.7rc1 and trunk)


Reproducible: Always
Steps to Reproduce:
1. Create a html document locally, saving it with one of .exe, .com, or .bin
extensions.
2. Load it in mozilla, e.g. select and paste.
Actual Results:  
1. "Opening ... What should Mozilla do with this file? ..."

Expected Results:  
Perform a more accurate type determination and render.

Comment 1

[jon rekai]

Attachment: testcase

Read from local filesystem.

Comment 2

[Boris Zbarsky [:bzbarsky]]

When reading from the local filesystem, we ask the OS for the type (at the
moment, on Unix, this is done by looking at the extension and looking it up in
the ~/.mime.types file, the /etc/mime.types file, and the gnome-vfs registry). 
If the OS has nothing to say, then we try to guess the file type on our own (and
we look at the extension before trying to look for HTML elements, since all
sorts of file contain random bits of HTML in them that aren't really HTML).

None of this has changed since 1.6, and I believe that this gives us the best
type determination in the common cases.  There's no way to 100% read people's minds.

If there's a way for us to get the type of a file from the OS on FreeBSD and
we're not using it, please enlighten me.

Comment 3

[Darin Fisher]

Slightly off-topic, but I think this bug might be best solved by extending the
"what do you want to do with this file?" dialog to include an option to tell the
browser to open it as HTML (or text, or maybe a user-specified mime type).  See
bug 57342, in fact.

Comment 4

[jon rekai]

Regarding comment 2, i did look a little further and did see that, but haven't
checked yet to see what, if anything, the OS is saying.  (There's no GNOME on my
FreeBSD boxes (just a couple of daemons;), but there are the 
/usr/share/misc/magic.mime* and an ancient ~/.mime.types which lacks the
extensions in question.)

Regarding
> None of this has changed since 1.6
My bad, incomplete info in the first comment- bin and exe were there, but com is
a somewhat recent addition it looks (which is where I first noticed it, saving a
web page as the domain name it was retrieved from then hitting the local copy).

Regarding comment 3, 
>"what do you want to do with this file?"
If all else fails, maybe, but with an opening HTML tag in the first few bytes,
we really shouldn't be getting there.  

Will see what the OS is saying  in these cases..

Comment 5

[Boris Zbarsky [:bzbarsky]]

> but with an opening HTML tag in the first few bytes,

You can't tell XHTML and HTML apart that way, unfortunately, and that is
absolutely a requirement for the content-sniffing code.  Hence looking at
extension (looking for "xhtml" and the like) before looking at the data.

Comment 6

[jon rekai]

Noted.

The thought of an optional OSMimeTypeProvider came up, but file -i doesn't fare
too well with some things, e.g. XML documents:|

Maybe this (bug) should be narrowed to: Does calling .com and .exe
application/octet-stream make sense on *NIX?  I.e. #elif defined(XP_UNIX) "bin"
#else "exe,com,bin"?

Comment 7

[timeless]

but ftp servers running unix could very well include windows binaries. or you
could very well download a windows binary for someone, or happen to browser your
windows drive. we shouldn't show those binaries as text/html...

the right thing to do is something like bug 57342, although i'd like to be able
to specify the mimetype instead of simply having view as text.

Comment 8

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

(In reply to comment #7)
> the right thing to do is something like bug 57342, although i'd like to be able
> to specify the mimetype instead of simply having view as text.

I certainly will allow other choices as well. some bug has some ascii art of a
ui spec...

Comment 9

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 10

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.