155830 - Show error in JS Console when image sent with wrong Content-Type (mime type)

Status: NEW

(Core :: Graphics: ImageLib, defect)

Description

[Christopher Hoess (gone)]

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

[Boris Zbarsky [:bzbarsky]]

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.

Comment 2

[Christopher Hoess (gone)]

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

[Boris Zbarsky [:bzbarsky]]

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.

Comment 4

[Christopher Hoess (gone)]

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?

Comment 5

[Dan Tobias]

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

[Boris Zbarsky [:bzbarsky]]

Dan: YES.  (Try disabling the guessing and browsing, ok?)

Comment 7

[Dan Tobias]

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

[Hixie (not reading bugmail)]

Every browser ever written has done MIME type guessing for images. All of them.
Without exception.

Comment 9

[Boris Zbarsky [:bzbarsky]]

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

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: 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.

Comment 11

[Boris Zbarsky [:bzbarsky]]

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

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: 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

Comment 13

[Boris Zbarsky [:bzbarsky]]

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

[Christian :Biesinger (don't email me, ping me on IRC)]

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

[Alec Flett]

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

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 181638 has been marked as a duplicate of this bug. ***

Comment 17

[Stuart Parmenter]

I don't really see a point in reporting these.  Can someone explain why this is
useful to real people?

Comment 18

[Dan Tobias]

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

[Boris Zbarsky [:bzbarsky]]

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

[Steve Chapel]

(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.