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
