Re: [whatwg] Script-related feedback

On Mon, Jan 7, 2013 at 7:51 PM, Ian Hickson <ian@hixie.ch> wrote:
> On Mon, 7 Jan 2013, Adam Barth wrote:
>> > Why not just introduce a keyword or pragma to JavaScript that tells
>> > the user agent to act as if the end of the Program production had been
>> > reached, and that it should treat the remainder of the file as another
>> > Program?
>> >
>> > This could even be done in a backwards-compatible fashion by having
>> > the syntax to do this be something that down-level clients ignore,
>> > e.g.:
>> >
>> >    /*@BREAK*/
>> >
>> > ...or some such.
>>
>> That approach is an in-band signal, which means it's vulnerable to
>> injection attacks.
>
> If you can inject this, you can inject arbitrary code, so I don't see how
> this would be a problem.
>
>> For example, consider a server that produces a JavaScript file of the
>> following form:
>>
>> [...]
>> var userData = "<?php echo santize($userData) ?>";
>> [...]
>>
>> Currently, the rules for sanitizing using input are relatively
>> straightforward (essentially, you just need to worry about a few special
>> characters).
>
> Those simple rules would prevent anyone from inserting a pragma-like
> comment, too, so that's fine.
>
>> However, if we implemented an in-band signaling we might well break
>> these sanitation algorithms.
>
> How? I'm not suggesting changing any JS syntax, just making existing JS
> syntax be used as a signal.
>
> If making a comment do this is too dodgy, make it something like this:
>
>    breakParsing();
>
> ...and for down-level support, define an explicit breakParsing function
> that does nothing. If someone can insert a function call into JS, you've
> definitely lost already.

Working through some examples, that seems really strange:

foo();
breakParsing();
bar();

In this case, breakParsing() works a bit like "yield()" in other
programming languages: first foo() executes, then the event loop
spins, then bar() executes.  However, if we wrap the code in an
anonymous function block (as would make sense for JavaScript):

(function() {
  foo();
  breakParsing();
  bar();
})();

Now I get either get a parse error, if breakParsing() actually breaks
up the parsing, or breakParsing() does nothing, both of which are
surprising.  Worse, other seemingly trivial syntactic transformation
also break the magic:

foo();
breakParsing.call();
bar();

Now the JavaScript parse won't recognize the magic "breakParsing();"
production, and my script executes slowly.

I guess I don't understand the advantage of trying to cram this into
JavaScript syntax.  It's really got nothing to do with JavaScript as a
language and everything to do with providing an efficient way for web
sites to ask the browser to execute several JavaScript programs in
sequence.

HTTP already has an efficient mechanism for delivering several
JavaScript programs in sequence: multipart.  Given that <img> and
<iframe> already support multipart, it seems much simpler just to make
<script> support multipart as well.

Adam

Received on Wednesday, 9 January 2013 08:23:36 UTC