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

[Ian Hickson]

On Tue, 4 Oct 2011, Odin Hørthe Omdal wrote:
>
> If the CORS-check did not succeed on <img
> src=http://crossorigin.example.net crossorigin>, this should happen
> according to spec:
> 
> > Discard all fetched data and prevent any tasks from the fetch algorithm from
> > being queued. For the purposes of the calling algorithm, the user agent must
> > act as if there was a fatal network error and no resource was obtained. If a
> > CORS resource sharing check failed, the user agent may report a cross-origin
> > resource access failure to the user (e.g. in a debugging console).
> 
> <http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#potentially-cors-enabled-fetch>
> 
> 
> In this scenario an author wanting to do some canvas processing with the
> image, will be able to check img.onerror to see whether she can use that
> image. The image won't load on a failed check. Gecko does this.
> 
> WebKit, on the other hand, only taints the image and loads it anyway,
> breaking the spec. The error will instead crop up in a way that is more
> verbose and harder to miss when she tries to read the image data out.
> 
> 
> Is WebKit's method a lesser surprise than the image just not showing up 
> (if they don't check for thrown error)? It'd be nice to hear why it's 
> implemented like that, if there are any good reasons. WebKit's method 
> seemed most obvious to me at first, but after investigating a bit I'm 
> not sure anymore...

The idea is that if the server explicitly rejected the CORS request, then 
the image should not be usable at all.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'