Bug 21226 - [Imports]: Components fetching should always use CORS.
[Imports]: Components fetching should always use CORS.
Status: RESOLVED FIXED
Product: WebAppsWG
Classification: Unclassified
Component: Component Model
unspecified
PC All
: P2 normal
: ---
Assigned To: Dimitri Glazkov
public-webapps-bugzilla
:
Depends on:
Blocks: 20683
  Show dependency treegraph
 
Reported: 2013-03-08 18:06 UTC by Dimitri Glazkov
Modified: 2013-09-19 01:55 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dimitri Glazkov 2013-03-08 18:06:46 UTC
Otherwise, there's a nasty side effect of being able to exploit a document by treating it as a component.
Comment 1 Anne 2013-03-28 19:46:48 UTC
There's also the opposite scenario of a hostile component.
Comment 2 Simon Pieters 2013-04-09 21:15:08 UTC
Please also see http://www.w3.org/mid/op.wuyfg2o4idj3kv@simons-macbook-pro.local
Comment 3 Dimitri Glazkov 2013-07-18 22:39:17 UTC
Did I get this right? https://dvcs.w3.org/hg/webcomponents/rev/27c0e8822ebb
Comment 4 Dimitri Glazkov 2013-07-18 22:48:17 UTC
3:42 PM <annevk> dglazkov: so now you cannot have CORS-cross-origin resources so that part of the spec doesn't make sense anymore
3:43 PM <annevk> dglazkov: you also need to say what happens if fetching failed
3:44 PM <annevk> I guess it's mostly fine otherwise, although I wonder if it shouldn't use a crossorigin attribute on <link> like most other things we have
Comment 5 Dimitri Glazkov 2013-07-19 17:27:58 UTC
(In reply to comment #4)
> 3:44 PM <annevk> although I wonder if it
> shouldn't use a crossorigin attribute on <link> like most other things we
> have

But then if you don't specify the attribute, you'll just have a No CORS state, right?
Comment 6 Anne 2013-07-19 17:46:33 UTC
The <track> element works like that, yes. No real opinion on what is better, but some consistency throughout would be good.
Comment 7 Morrita Hajime 2013-09-19 01:55:40 UTC
(In reply to Anne from comment #6)
> The <track> element works like that, yes. No real opinion on what is better,
> but some consistency throughout would be good.

For <track>, it makes sense to load it but not to expose the detail through API. So having @crossorigin (on its parent <media>) makes sense. However for imports, it doesn't make sense to do that: Unlike movie subtitles, API-invisible imports aren't useful at all.

Theoretically we could possibly have @crossorigin for imports so that the author can make requests with credentials. But I don't see any usecase for that.
In contrast, not having @crossdomain makes the usage easier/simpler. If we introduce @crossorigin, people needs to give @crossorigin all the time once they want it CDN-aware, which is sad. I prefer to have better default than to just make the orange consistent to apples.

I'm closing this for now. Feel free to reopen this to continue conversation.