Mark S. Miller
erights at google.com
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 google.com> wrote:
> 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