v1.6 Chrome/Firefox Fix Update

[jeremyruppel]

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

[jeremyruppel]

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.

[GreenSock]

Aha, great catch. Thanks for pointing that out, although your patch won't work correctly for files on the local file system. I've fixed the latest version and it's available now on the main site (

[jeremyruppel]

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.

[GreenSock]

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.

Yep, I tried to explain it in detail in that post you linked to: viewtopic.php?f=6&t=3652#p14275

 

Did I do a poor job of explaining it there?

 

It's actually very important that the cacheBusterID be appended for the audit to work around the bugs that occasionally pop up in Chrome/Firefox. I can't imagine any down side to it either - is there some reason you'd object?

[jeremyruppel]

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.

[GreenSock]

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?

 

No no, it's exactly the opposite. The cacheBusterID is absolutely necessary and is itself the fix described in that thread. The entire purpose of the fix revolved around adding the cacheBusterID to all audits in order to work around the browser bugs. See what I mean?

 

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.

I think you're misunderstanding how this works. The cacheBusterID is only forced on audits which DO NOT load the whole file and should NEVER be cached. Let's say you have a 50MB video. When (and if) LoaderMax audits the file size, it opens a URLStream for the sole purpose of querying the file size from the server. Once it gets the first piece of the file (let's just say 0.02kb worth), it immediately closes the connection and terminates the request. Mission accomplished. bytesTotal is now accurate. LoaderMax moves on and once all audits are complete, it begins doing the full "official" loading of the files. There is no real benefit to be had by utilizing those 0.02kb from the URLStream in cache. In some browsers, that actually would lead to problems (as described in the previous thread).

 

Audits have nothing to do with actually loading the real file in its final/complete form. When LoaderMax makes the "real" request for the file (after an audit if one was necessary), it will ONLY apply the cacheBusterID if you specifically request it with noCache:true. The default behavior is NOT to append cacheBusterID. So cache busting is indeed optional, and off by default (except for audits of course).

 

Where you under the impression that cacheBusterID is not optional for the real file loads? Did you think there was some down side to appending it to the audits? If so, please explain - I can't fathom how there would be any benefit to removing the cacheBusterID in audits. I only see problems arising from making it optional, but maybe I'm missing something.

[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!

[GreenSock]

Ah, my fault, Jack. Sorry for the confusion...Looks like this indeed does the trick, thanks!

No problem. Thanks again for the assist.