W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2011

[whatwg] [CORS] WebKit tainting image instead of throwing error

From: Odin Hørthe Omdal <odinho@opera.com>
Date: Thu, 06 Oct 2011 18:39:49 +0200
Message-ID: <op.v2xu8nvp49xobu@id-c0850>
On Thu, 06 Oct 2011 18:11:54 +0200, Adam Barth <w3c at adambarth.com> wrote:

>> If they actually want a fallback, they can easily just reload the  
>> picture
>> without crossorigin, and they will probably get the cached image  
>> directly
>> from the browser (because it already has it, only won't show it).
>> Obviously, if there hadn't been a crossOrigin-attribute, this would be  
>> the
>> nice way to handle all image fetching.
> It sounds like you're arguing that it's better for developers if we
> fail fast and hard, which is the opposite of how most of the web
> platform is design (vis HTML versus XML).
> The arguments revolving around wishful thinking about how the world
> should have been don't carry much weight for me.

Well, you're violating the specification. And this is something quite  
different from XML versus HTML.

And also, we're doing the same on XHR. If you set xhr.withCredentials and  
the server do allow your origin, but doesn't allow credentials, you just  
don't send a request without credentials and hope the author doesn't see  
it. That will throw an error.

For new stuff like this, there's no reason being loose. If something  
doesn't work in any browser at all, they will fix it, if it works in one,  
but not any other they will think all the other browsers are doing  
something wrong.

In the spec, you'll get "notified" that your picture won't be tainted, --  
in WebKit's implementation it will just crash when you really try.

Anyway, for my part we could've just not had the "crossorigin" attribute  
at all, and just send Origin-header to all cross-origin images. But then  
everyone needs to do the same thing, and it would apparently also break  
some sites (  

Received on Thursday, 6 October 2011 09:39:49 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:37 UTC