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.
Assignee: neeti → dougt
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
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 → ---
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
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.
mass move, v2. qa to me.
QA Contact: tever → benc
what is milestone "mozilla1.0" anyway? Moving to future.
Target Milestone: mozilla1.0 → Future
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 ago → 18 years ago
Resolution: --- → WORKSFORME
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.