[whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests
Anne van Kesteren
annevk at opera.com
Mon Mar 16 06:43:32 PDT 2009
On Mon, 16 Mar 2009 14:07:38 +0100, Hans Schmucker
<hansschmucker at gmail.com> wrote:
>> Why does the DOM need to get involved here?
> Well it should be involved, although I don't think we can actually do
> it. I think the CORS header response should be stored and be available
> the same way across all DOM elements that can load data. If that would
> be provided by a special interface from which all elements that load
> data descend, it would not only make the whole thing cleaner in the
> spec, but also in the implementations.
If the specifics are not exposed to authors the DOM does not need to get
> Instead of an UA supporting
> first XHR, then image, then video, then XY, the status of the
> implementation would be identical in all parts of the UA. Basically,
> it would force implementations to create the CORS dom support with a
> common codebase for all elements that use it, instead of having
> duplicate code which might behave differently.
I don't think we should be in the business of enforcing how
implementations implement things. We can certainly encourage things by
re-using algorithms, indicating things are identical, etc., but if there
is no author-observable difference we cannot test it.
>>> Then there's the (IMHO) despicable way of just writing a random
>>> chapter about it and referencing that chapter in the spec wherever
>>> appropriate. Feels very, very wrong, but I don't think we have much
>>> choice here.
>> I don't see how this is wrong. Since the exact semantics of a
>> cross-origin request vary per API anyway grouping the common things
>> somewhere makes sense to me. (E.g. EventSource would completely fail in
>> case the resource sharing check fails where as an image would still be
> Reading this again the next morning I really should have worded that
> differently. Sorry about that. But I'm really afraid JS developers, in
> addition to catching different behaviours in different UAs would also
> have to deal with different behaviour inside the same UA. Yes, the
> actual use would be different across different cases, but at least the
> raw data would be readable the same way and the parts that implement
> the different uses would have a standardized to where to get their
> data from.
Consistency is enforced by tests and proper specifications. Currently
HTML5 has not integrated support for CORS (yet) so it seems a bit early to
Anne van Kesteren
More information about the whatwg