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 <[email protected]> wrote: > On Tue, Apr 9, 2013 at 7:32 AM, Sam Tobin-Hochstadt <[email protected]>wrote: > >> On Tue, Apr 9, 2013 at 10:11 AM, Anne van Kesteren <[email protected]> >> wrote: >> > On Tue, Apr 9, 2013 at 2:58 PM, Sam Tobin-Hochstadt <[email protected]> >> wrote: >> >> On Tue, Apr 9, 2013 at 6:36 AM, Anne van Kesteren <[email protected]> >> 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 >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > > > > -- > Cheers, > --MarkM > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
