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.
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.
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...
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.
Summary: MIME-type handling breaks HTTP spec → Show error in JS Console when image sent with wrong Content-Type
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?
Dan: YES. (Try disabling the guessing and browsing, ok?)
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.
Every browser ever written has done MIME type guessing for images. All of them. Without exception.
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.
Created attachment 121852 [details] [diff] [review] show warning in console on mismatch 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.
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?)?
Created attachment 121854 [details] [diff] [review] better patch 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
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? ;)
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 :)
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.
*** Bug 181638 has been marked as a duplicate of this bug. ***
16 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)
I don't really see a point in reporting these. Can someone explain why this is useful to real people?
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.
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).
(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.
You need to log in before you can comment on or make changes to this bug.