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

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

From: Hans Schmucker <hansschmucker@gmail.com>
Date: Mon, 16 Mar 2009 14:07:38 +0100
Message-ID: <f7458d480903160607p27dd1a9cg13c2adde71383f2@mail.gmail.com>
>> So, where would you put it? The problem for me is that there's no
>> logical grouping of elements that load offsite resources (like img,
>> script, link, video, ...) where one could add the necessary
>> attributes. All off them descend directly from HTMLElement. So there
>> would be two routes: Either making all elements that load offsite data
>> descend from a common HTMLRemotelyFedElement interface (which seems
>> like the right way to do things, but it's also IMHO completely
>> unrealistic as it would either require reworking the DOM top to bottom
>> or including ugly hacks) or adding the necessary attributes to
>> HTMLElement itself... which seems like asking for trouble.
>
> 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. 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.


>> 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.
Received on Monday, 16 March 2009 06:07:38 GMT

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