W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2009

[whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests

From: Anne van Kesteren <annevk@opera.com>
Date: Mon, 16 Mar 2009 14:43:32 +0100
Message-ID: <op.uqv0eugw64w2qv@annevk-macbook.lan>
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  
involved.


> 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  
>> displayed.)
>
> 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  
complain :-)


-- 
Anne van Kesteren
http://annevankesteren.nl/
Received on Monday, 16 March 2009 06:43:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:47:49 GMT