[Webkit-unassigned] [Bug 47512] Add support for decoding WebP image

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=47512





--- Comment #14 from Peter Kasting <pkasting at google.com>  2010-10-12 21:47:52 PST ---
(In reply to comment #13)
> > It's not going to be a huge deal to change this code.  But the code assumes that it sits underneath other sniffing/parsing code that has already made a determination that this bytestream should be fed to the ImageDecoder.
> 
> I don't believe that's correct.  If you point an <img src="..."> at an URL, the bytes you get back to the server will come to this function.
> 
> Now, you might say that the result is indistinguishable because the image library will reject files that don't have the proper format, but that assumes the image library is correct and/or bug free.

You're getting ahead of me.  I don't know what correct result you're expecting me to argue our behavior is indistinguishable from.

I thought the thrust of your concerns was the sniffing algorithm that determines a MIME type from a series of bytes.  The code in ImageDecoder is not determining a MIME type.  It is also not determining whether something is an image.  It is being called by code asserting that the bytestream in question _is_ an image, and being asked to best-effort decode it.  That's a different task entirely.  (One notable point is that we purposefully support certain invalid images so we can at least partially decode them.  Now, I don't believe any of the "invalid" things we allow happen to be changes in what you've marked as the signature bytes, but the point remains that the purpose of this code seems different than the purpose of code you care about.)

After that point, if you still insisted this code were subject to the comments in http://tools.ietf.org/html/draft-abarth-mime-sniff-05#section-6, I would say that it is the combined duty of the entire ImageDecoder subsystem to correctly validate images, and that which part is implemented in ImageDecoder::create() versus GIFImageDecoder.cpp versus GIFImageReader.cpp is not properly your concern as long as the result matches your criteria.  ...Which isn't really even a sane concept to discuss because there is far more to a valid image than just the first few signature bytes, so I'm not sure what "matches your criteria" even means.

You need to come by my desk and talk to me about the practical concerns you have because this conversation is not helping me understand them.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.