Mark S. Miller
erights at google.com
Tue Apr 9 08:51:30 PDT 2013
On Tue, Apr 9, 2013 at 7:32 AM, 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>
> > On Tue, Apr 9, 2013 at 2:58 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu>
> >> On Tue, Apr 9, 2013 at 6:36 AM, Anne van Kesteren <annevk at annevk.nl>
> >>> 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.
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss