Closed
Bug 75758
Opened 24 years ago
Closed 23 years ago
need to handle files with no extensions (set better file type)
Categories
(Core :: Networking, defect)
Tracking
()
RESOLVED
WORKSFORME
Future
People
(Reporter: Brade, Assigned: dougt)
References
Details
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 | ||
Comment 2•24 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
Closed: 24 years ago
Resolution: --- → INVALID
Comment 3•24 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•24 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•24 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.
Assignee | ||
Comment 7•23 years ago
|
||
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
Closed: 24 years ago → 23 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.
Description
•