[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
unclear?
>> 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.
-Boris
More information about the whatwg
mailing list