Open
Bug 155830
Opened 22 years ago
Updated 2 years ago
Show error in JS Console when image sent with wrong Content-Type (mime type)
Categories
(Core :: Graphics: ImageLib, defect)
Core
Graphics: ImageLib
Tracking
()
NEW
People
(Reporter: choess, Unassigned)
References
()
Details
Attachments
(1 file, 1 obsolete file)
3.80 KB,
patch
|
Details | Diff | Splinter Review |
AIUI, ImageLib now uses the HTTP-supplied Content-Type only in an accessory role. This violates RFC 2616, which says we should only guess Content-Type if one is not supplied by the server. The behavior should be changed to only sniff the MIME-type if none is supplied.
Comment 1•22 years ago
|
||
Doing this would 1) Break lots of sites 2) Not be useful, since our type-detection code is pretty good (unlike some servers) and image types all have well-defined magic numbers. Finally, I'm pretty sure this is a duplicate. Please find the (likely WONTFIX) original and dup this.
Reporter | ||
Comment 2•22 years ago
|
||
bug 126067, I suppose, but before I dupe it, why don't we check for standards mode? The sort of layouts people do in standards mode are pretty heavily dependent on CSS, and I'd think that having their images disappear would probably do about an equivalent amount of damage...
Comment 3•22 years ago
|
||
I don't feel this should be handled differently between the two modes, since once again image types have well-defined, standardized, and registered magic numbers. Thus detection of image types by looking at the magic numbers is quite reliable.
Reporter | ||
Comment 4•22 years ago
|
||
For the time being, can we consider reporting MIME-type mismatches between the HTTP header and the type detected by imglib to the Javascript Console, as we do with stylesheets?
Reporter | ||
Updated•21 years ago
|
Summary: MIME-type handling breaks HTTP spec → Show error in JS Console when image sent with wrong Content-Type
Comment 5•21 years ago
|
||
I don't like browsers doing any sort of MIME-type second guessing, as it is against the standards, encourages webmasters and server administrators to be lazy, and creates security risks where malicious content can be "snuck past" a firewall under a fake MIME type and still executed at the other end. Also, second-guessed MIME types sometimes cause things to fail (try and send "text/plain" content as the output of a CGI script to MSIE; it's a crapshoot whether it allows you to see it as plain text as intended). It's true that inline image display is a special case that doesn't have as many practical problems, but on principle I'm still against this second-guessing. Are there really that many servers that have the basic image types misconfigured?
Comment 6•21 years ago
|
||
Dan: YES. (Try disabling the guessing and browsing, ok?)
Comment 7•21 years ago
|
||
I'm not sure where the pref to disable the guessing is (or maybe I'm still using a build before the guessing was added? When was that "feature" put in?) Did Netscape versions 0.9 through 4.77 have this "feature"? Did any pre-1.3 Mozillas? If not, then the browsers I've used as my primary browser since 1995 didn't do this second-guessing of images, so it's hardly something that urgently needed adding to preserve my browsing experience.
Comment 8•21 years ago
|
||
Every browser ever written has done MIME type guessing for images. All of them. Without exception.
Comment 9•21 years ago
|
||
Every single version of Netscape and Mozilla does this guessing, as does every single version of every graphical browser I have ever tried (this includes Amaya, Konqueror, Opera, IE, Netscape of all versions, Mozilla of all versions; I have not tried iCab or OmniWeb). I don't recall whether Mosaic did the guessing, but I could probably dig it up and check if you really really care. And there is no pref. You'd have to modify the code a bit.
Comment 10•21 years ago
|
||
note, though, that with this patch the text is not localizable but making it localizable would require REQUIRE-ing intl, which I'm hesitant to do.
Comment 11•21 years ago
|
||
Would that warn for image/pjpeg? Or do we detect that differently than image/jpeg? The console service situation with requiring intl is ridiculous.... I'm not quite sure what we can do about it, though. Perhaps string bundles should move out of intl and into something closer to the core (xpcom?)?
Comment 12•21 years ago
|
||
also show url in console message bz: Hmmmmm. You have a good point there. But I am not sure what the best solution is there... As for the console service, yeah, I agree... but that's kinda outside the scope of this bug
Attachment #121852 -
Attachment is obsolete: true
Comment 13•21 years ago
|
||
Yeah, see http://lxr.mozilla.org/seamonkey/source/modules/libpr0n/build/nsImageModule.cpp#116 -- almost every decoder actually supports multiple equivalent types. Perhaps a better way would be to instantiate the decoder, then have a function on it to ask it whether it can handle a particular type. Then warn if the decoder we instantiated does not actually handle the type the image was sent with. Something like "Warning: the image at http:// has a content-type that does not match the image data". That may also allow us to eliminate that hardcoded list of types in nsImageModule, maybe? Not sure... Anyway, what are the chances pav will take this patch? ;)
Comment 14•21 years ago
|
||
that idea would not allow eliminating that list. that list is used for
registering the image mime types with the category manager (the
Gecko-Content-Viewers category).
That said, the idea sounds good to me.
>Anyway, what are the chances pav will take this patch? ;)
good question :)
Comment 15•21 years ago
|
||
the "intl" module IS string bundles - there is nothing else in that module. We could potentially do a tree-wide search/replace for "intl" -> "strres" but it doesn't seem worth the effort.
Comment 16•21 years ago
|
||
*** Bug 181638 has been marked as a duplicate of this bug. ***
Updated•21 years ago
|
Summary: Show error in JS Console when image sent with wrong Content-Type → Show error in JS Console when image sent with wrong Content-Type (mime type)
Comment 17•21 years ago
|
||
I don't really see a point in reporting these. Can someone explain why this is useful to real people?
Comment 18•21 years ago
|
||
Mozilla already reports in the console that a stylesheet was sent with the wrong MIME type, so doing the same for images makes just as much sense. This can be a useful feature for Web developers checking whether everything in their site is valid and standards-compliant.
Comment 19•21 years ago
|
||
Note that we only report this for CSS because if the site switches to a standards doctype we will start NOT LOADING the CSS. This is not really the case for images.... (not that I have views either way on this bug).
Comment 20•19 years ago
|
||
(In reply to comment #17) > I don't really see a point in reporting these. Can someone explain why this is > useful to real people? View Image sometimes doesn't work for images that are sent with the wrong MIME type. See the URL, for example.
Updated•17 years ago
|
Assignee: pavlov → nobody
QA Contact: tpreston → imagelib
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•