Anne van Kesteren
annevk at annevk.nl
Tue Apr 9 07:11:25 PDT 2013
On Tue, Apr 9, 2013 at 2:58 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:
> On Tue, Apr 9, 2013 at 6:36 AM, Anne van Kesteren <annevk at annevk.nl> 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>?
>> 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
> 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
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.
>> 3) The request.redirect() callback should be invoked with an absolute
>> URL. No need to leave resolving the URL correctly up to developers.
>> 3a) Why are redirects up to the developer however? Every other part of
>> the platform handles them automatically.
> Our current plan is to eliminate the `redirect` response entirely.
More information about the es-discuss