jeremyruppel

Ah, my fault, Jack. Sorry for the confusion. The previous version of LoaderItem.auditSize altered the URLRequest's url directly, which would mean that the cacheBusterID would be appended to the actual load no matter what if size was audited (see the screenshot in my initial post, I was not opting in to noCache). Looks like this indeed does the trick, thanks!

The fix you just made as a result of this thread would fix the issue you described in that post, so the cacheBusterID is unnecessary, right? As far as the cacheBusterID being harmless, I've worked on projects that use services like Akamai to distribute their content, a major benefit of which is caching within the CDN. For this reason, I definitely believe that the cacheBusterID functionality should be opt-in in all cases.

Awesome! Thanks for the quick response! One question though, is there a reason that the cacheBusterID must be appended if a file is to be audited? To me, it feels like those features should be separate.

To elaborate even further, auditing size post v1.6 does in fact introduce the cacheBusterID for the LoaderItem's url regardless of whether the vars.noCache property has been set to true, as mentioned in this previous post: http://forums.greensock.com/viewtopic.php?f=6&t=3652. The fix proposed in this thread leaves the original request's url intact.

Hey Jack, Was looking through the changelog for v1.6 and realized you had addressed a bug I had been seeing on a recent project regarding Firefox and Chrome caching the URLStream used to audit the size of a load. However, your fix in LoaderItem.as isn't correct. Applying the cacheBusterID to the LoaderItem's URLRequest will still give the audit stream and load proper the same url, so the stream could still get cached. Here's a screenshot of the post-v1.6 behavior in action as seen through Charles: As you can see, the helvetica-neue.swf loads twice, once for the audit, once for the load, but the second load is half the size. This swf is 80K+. Notice that the cacheBusterID for each request is the same, this is the issue. My fix has been to remove the cacheBusterID assignment from LoaderItem.auditSize and to make the URLStream use a different URLRequest with an explicitly different query string parameter than the actual request to ensure we will always avoid caching the audit. /*_applyCacheBuster(); //to work around bugs in Chrome and Firefox that can cause them to use the partially-loaded audit file in the cache instead of loading the full file normally.*/ /*_auditStream.load(_request);*/ _auditStream.load( new URLRequest( _url + ((_url.indexOf("?") == -1) ? "?" : "&") + 'purpose=audit' ) ); Hope this helps, and thanks for all your work. J