Re: [whatwg] Script-related feedback

On Wed, Dec 19, 2012 at 2:27 PM, Ian Hickson <ian@hixie.ch> wrote:
> On Mon, 3 Dec 2012, Adam Barth wrote:
>> Currently, there are a number of ways to load a script from the network
>> and execute it, but none of them will actually load and execute the
>> script as fast as physically possible.  Consider the following markup:
>>
>> <script async src="path/to/script.js"></script>
>>
>> In this case, the user agent will wait until it receives the last byte
>> of script.js from the network before executing the first byte of
>> script.js.
>
> It had better, since JavaScript requires that syntax errors in the lasy
> byte prevent execution of the first byte.
>
>> The main ingredient that we're missing is a way for the author to signal
>> to the user agent which chunks of scripts are safe to execute in
>> parallel with loading subsequent chunks from the network. Fortunately,
>> the web platform already has a mechanism for breaking a single HTTP
>> response body into chunks that are processed sequentially:
>> multipart/mixed.
>>
>> For example, if an HTTP server provides a multipart/mixed response to a
>> request for an image, the <img> element will display each part of the
>> response in sequence, animating the image.  Similarly, if an HTTP server
>> provides a multipart/mixed response to a request for an HTML document,
>> the user agent will display each part of the response sequentially.
>>
>> One way to address this use case is to add multipart/mixed support to
>> the <script> element.  Upon receiving a multipart/mixed response to a
>> request for a script, the <script> element must execute each part of the
>> response as they become available.  This behavior appears to be
>> consistent with the definition of multipart/mixed
>> <http://tools.ietf.org/html/rfc2046#section-5.1.3>.
>>
>> To load and execute a script as quickly as possible, the author would
>> use the following markup:
>>
>> <script async src="path/to/script.js"></script>
>>
>> The HTTP server would then break script.js into chunks that are safe to
>> execute sequentially and provide each chunk as a separate MIME part in a
>> multipart/mixed response.
>
> This seems like an overly complicated way of solving this problem.
>
> 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.  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).  However, if we implemented an in-band signaling
we might well break these sanitation algorithms.

To make this secure, we'd probably want some sort of randomized
delimiter (perhaps declared via a pragma at the top of the file), but
then we would have just re-invented multipart/mixed.

Adam

Received on Tuesday, 8 January 2013 01:21:11 UTC