[whatwg] [CORS] WebKit tainting image instead of throwing error
ian at hixie.ch
Tue Oct 4 11:32:02 PDT 2011
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).
> 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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg