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

NEW
Unassigned

Status

()

17 years ago
5 years ago

People

(Reporter: choess, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

17 years ago
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.
(Reporter)

Comment 2

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

16 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

16 years ago
Summary: MIME-type handling breaks HTTP spec → Show error in JS Console when image sent with wrong Content-Type

Comment 5

16 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?
Dan: YES.  (Try disabling the guessing and browsing, ok?)

Comment 7

16 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.
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 :)

Comment 15

16 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.
*** Bug 181638 has been marked as a duplicate of this bug. ***
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

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

Comment 18

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

14 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

12 years ago
Assignee: pavlov → nobody
QA Contact: tpreston → imagelib
You need to log in before you can comment on or make changes to this bug.