need to handle files with no extensions (set better file type)

RESOLVED WORKSFORME

Status

()

RESOLVED WORKSFORME
18 years ago
17 years ago

People

(Reporter: Brade, Assigned: dougt)

Tracking

Trunk
Future
PowerPC
Mac System 8.5
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
From bug #64704:  Necko needs to be more intelligent about setting the file type
from the mimetype rather than relying on the file extension.  The front-end
should avoid content sniffing.

DougT notes:  Necko provides the content type via the nsIChannel, and there is a
MIME service for getting the content type for an extension.
(Reporter)

Updated

18 years ago
Blocks: 64704

Comment 1

18 years ago
-->dougt
Assignee: neeti → dougt
(Assignee)

Comment 2

18 years ago
we do are best.  if the http server does not set the mimetype, and the file does 
not have an extension, there is nothing we can do.  Please see my comment in bug 
64704.  Marking INVALID
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → INVALID

Comment 3

18 years ago
There is something we can do. We can look at the file contents. We should be able 
to reliably identify HTML, JPEG, GIF, and lots of other file types this way.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
(Assignee)

Comment 4

18 years ago
i understand... crack the file open and guess what it is.  I thought that we do 
that somewhere... maybe layout... 

So, given a very small buffer of the file, we need to ask the mime service if it 
known what the file is.  
Target Milestone: --- → mozilla1.0

Comment 5

18 years ago
we already parse unknown files using nsUnknownDecoder.cpp which is a stream 
converter that is envoked in nsURILoader.cpp.

the order of precedence is (winning-most at the top)...
- HTTP MIME-type from the server
- file extension to mime type mapping. Uses nsMIMEService which maintains our 
own hard coded list of extensions to MIME types (or IP config on the mac)
- byte sniffing in the uri loader (front end, nsUnknownDecoder.cpp)

if someone has a better model, please step up w/ it.

Comment 6

18 years ago
mass move, v2.
qa to me.
QA Contact: tever → benc
(Assignee)

Comment 7

18 years ago
what is milestone "mozilla1.0" anyway?  Moving to future.
Target Milestone: mozilla1.0 → Future

Comment 8

18 years ago
I'm going to resolve this, b/c I can't think of a better way of doing this.
There are various bugs on places people think we should DO this and we don't
(like opening file URL's w/ no extensions in the file name.

The actual content determination approach seems solid to me.
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → WORKSFORME

Comment 9

17 years ago
reporter:

This bug is a "futured" or "untargeted" bug which has been "resolved/works for
me". Most bugs meeting this criteria are usually somewhat out of date or working
in the current builds.

If this bug is not happening for you in a recent build (such as the Mozilla
daily build, Mozilla 0.9.3, or Netscape 6.1), please use the friendly "Mark bugs
as VERIFIED" radio button to set this bug to "VERIFIED/WORKS FOR ME"
If you reported the bug on a platform (e.g. Linux) and other contributors
reported on another platform (e.g. Mac OS), please comment that it works for you
 but do not verify it yet.

For these multi-platform bug reports, we need to verify all reported platforms
-OR- create new "still broken on platform X" bugs when you verify.
You need to log in before you can comment on or make changes to this bug.