- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 22 Feb 2011 13:54:10 -0500
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
Received on Tuesday, 22 February 2011 10:54:10 UTC