[whatwg] Proposal for separating script downloads and execution

Boris Zbarsky bzbarsky at MIT.EDU
Tue Feb 22 10:54:10 PST 2011

On 2/22/11 1:50 PM, Kyle Simpson wrote:
>>>> 1) If your script is no-cache, or max-age:0, does IE make a new
>>>> request for it for every<script> element?
>>> For the most part this seems to be the case but there are two
>>> exceptions:
>>> a) Before a URL loads, if it's assigned to another script, only one
>>> request is made.
>> OK, that would be a violation of the HTTP caching semantics.
> Can you explain how, in more detail? In practice I haven't seen IE's
> behavior be a problem, but perhaps I'm not seeing the full context of
> the issue you're concerned with.

If I have a response set to no-cache and you make two requests for it 
but only one of those actually hits the server, then you're clearly 
caching it in violation of the no-cache header.  Is that really that 

>> Uh... In that situation I would expect the event handler to keep the
>> script alive until the load finishes. Anything else is just a bug that
>> exposes GC timing to the web page.
> I've said the same thing to Will before. I agree that a script having a
> circular reference to itself via the closure that's created when its
> handler is created and assigned... *should* have kept the item alive and
> not GC'd. I don't understand why IE GC's in this way.

Because it's the easy way to do it; we had to jump through some hoops in 
Gecko to make sure an async XHR stays alive until it fires its last 
readystate change event when no one is holding a ref to the XHR object.

> In any case, for all intents and purposes, for someone to be using the
> "preloading" as we're suggesting (with either proposal), you'd have to
> keep around a reference to the script element anyway, so that you could
> later programmatically execute it.

Well... no.  You could grab the ref in the onreadystatechange handler.


More information about the whatwg mailing list