Module loader

Anne van Kesteren annevk at annevk.nl
Tue Apr 9 07:40:41 PDT 2013


On Tue, Apr 9, 2013 at 3:32 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:
> On Tue, Apr 9, 2013 at 10:11 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
>> 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.  Additionally, it's my understanding that
> the ability of <script> to avoid CORS is a legacy compatibility issue,
> rather than an intentional design.
>
>> It's what we do for workers and basically any new type of text
>> resource. We want to avoid exposing new features to the complexity of
>> encodings, the security implications around them, and various other
>> issues that keep cropping up. Furthermore, by standardizing these new
>> formats on utf-8 we encourage everyone to move to that format and
>> avoid these issues.
>
> In that case, it's substantially more difficult to describe the
> behavior of existing platform behavior in terms of the module loader
> API.  Additionally, since the module system is designed to allow
> smooth migration from existing code, this seems like it could make
> developers lives more difficult in unexpected ways.

You realize these two answers are contradictory right?

If you do a CORS-enabled fetch by default, you also need to decide on
whether that will include credentials or not. Currently that is
typically exposed as flag in the platform (see with
XMLHttpRequest.withCredentials). It's not entirely done yet, but
http://fetch.spec.whatwg.org/#requests might give you an idea what
kind of things you need to take into consideration when designing
something new that fetches.


--
http://annevankesteren.nl/


More information about the es-discuss mailing list