Module loader

Mark S. Miller erights at
Tue Apr 9 08:54:53 PDT 2013

Sorry, not preflight. Anne is right -- a normal GET does not require
a preflight. Rather, the UMP and CORS cost that would be good to avoid if
we can is the need for the need for the "Access-Control-Allow-Origin: *"
header. But the conclusion is the same. Given a choice between this and
credentials, I'd prefer to require this header.

On Tue, Apr 9, 2013 at 8:51 AM, Mark S. Miller <erights at> wrote:

> On Tue, Apr 9, 2013 at 7:32 AM, Sam Tobin-Hochstadt <samth at>wrote:
>> On Tue, Apr 9, 2013 at 10:11 AM, Anne van Kesteren <annevk at>
>> wrote:
>> > On Tue, Apr 9, 2013 at 2:58 PM, Sam Tobin-Hochstadt <samth at>
>> wrote:
>> >> On Tue, Apr 9, 2013 at 6:36 AM, Anne van Kesteren <annevk at>
>> 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.
> Hi Sam, I don't recall this being discussed before. Perhaps I missed it.
>>  Additionally, it's my understanding that
>> the ability of <script> to avoid CORS is a legacy compatibility issue,
>> rather than an intentional design.
> Most of the bizarreness of CORS are also driven by legacy compatibility
> issues and are best avoided if we can.
> Most importantly, we should *not* send credentials by default, as this
> creates confused deputy hazards. Best would be to do an origin-independent
> http[s] GET without preflight (as script tags do) and without credentials
> (as UMP does and CORS does by default). This combination of "without"s
> would be new, and would be in the no man's land between the jurisdictions
> of w3c and tc39, so it is probably impossible to have a sensible
> conversation that arrives at a sensible conclusion. Given a choice between
> preflight (the UMP and CORS cost) and credentials (the script-tag cost),
> preflight is probably the better price to pay.
>> >>> 2) I think we should force utf-8 decoding on these new types of
>> >>> resources just as we do with workers and anything else that's new and
>> >>> text.
>> >>
>> >> Which step are you referring to?  The module loader API is defined
>> >> entirely in terms of JS strings, not encoded data. If you're
>> >> suggesting that the default module loader should have different
>> >> decoding behavior than <script> or <script src="">, then my initial
>> >> thought is that that would be a mistake, but I'd be interested in your
>> >> rationale.
>> >
>> > 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.
>> Sam
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at
> --
>     Cheers,
>     --MarkM

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list