Module loader

David Bruant bruant.d at gmail.com
Tue Apr 9 08:03:38 PDT 2013


Le 09/04/2013 16:32, Sam Tobin-Hochstadt a écrit :
> On Tue, Apr 9, 2013 at 10:11 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
>> On Tue, Apr 9, 2013 at 2:58 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:
>>> On Tue, Apr 9, 2013 at 6:36 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
>>>> 1) There should be a way to opt into CORS for cross-origin remote
>>>> script debugging.
>>> What exactly do you mean here?  Our plan is that the module loading
>>> facility would follow CORS automatically.  This will require slight
>>> modification to the current design to support the current
>>> CORS-ignoring behavior of <script src="">.  In particular, some
>>> requests will not go through the translation and link hooks.  However,
>>> what would opting in to CORS involve, and who would be doing it?
>> What do you mean by "follow CORS automatically"? Are you introducing
>> fetch semantics that differ from <script>?
> Yes, the default fetch behavior will be to follow CORS, rather than to
> behave like <script>. This is the only way that things like the
> translate hook make sense.
Why is it the only way?

> Additionally, it's my understanding that
> the ability of <script> to avoid CORS is a legacy compatibility issue,
> rather than an intentional design.
Opinions differ. Some would say the Same Origin Policy is a legacy 
compatibility issue. I'm of that side. It's pretty annoying that a 
server-side opt-in is required for sharing. It would be lovely if 
sharing on the web was as simple as sharing a URL [1]. It very often 
isn't (cookies, CORS as an opt-in).
Anyway, the web have survived until 2013 to cross-domain scripts; I 
don't think modules add security issues, so I don't see a reason module 
imports should act differently than <script>. Especially given how easy 
it is to confine a module.

Following CORS for module imports would make fetching a module require 2 
HTTP round-trips (one for the pre-flight IIUC) which is a bummer for 
performance.
CDN would need to add CORS headers (though maybe HTTP 2 will be there 
and the need for CDN will be different)
It would make using modules more annoying than script at src and the 
consequence of that could range from slowed-down adoption to people just 
never bothering transitioning to modules.

David

[1] http://waterken.sourceforge.net/web-key/


More information about the es-discuss mailing list