noCache - removing cacheBuster

[droyde]

Hi Jack,

I really do need your hand here just trying to remove cacheBuster as my project requires to use cache by special request. So I did try like this:

new ImageLoader("path", {name:"name", noCache:false})

 

That doesn't make any different at all. Any idea?

 

Thanks in advance!

[GreenSock]

Are you saying that if you set noCache:false that all your URL requests still have the cacheBusterID on the end? Remember, the auditing of file sizes will (and should) always have cacheBusterID in order to work around bugs in some browsers that can cause partially downloaded files to be used instead of the full ones. But if you set noCache:false (which is what it is by default anyway), your non-auditing requests should not have any cacheBusterID appended. If you think it's still getting appended, please explain why you think that and how I can reproduce the issue.

[droyde]

Here's basically the lines of code I have. I used the lastest greensock.swc. And I'm still geting this image.jpg?purpose=audit&cacheBusterID=1290246781514 at the back of image load.

 

_loader = new LoaderMax({name:"mainQueue", onComplete:completeHandler});

_loader.unload();

_loader.empty(true, true);

_loader.append(new ImageLoader(url, {name:"image", noCache:false}));

_loader.load();

 

Tested it on Chrome and Firefox. Please advice what I should do to just get rid of the cacheBusterID. It's quite annoying that it doesn't work. Thanks in advance.

[droyde]

Here's the attachment. What basically happened is the main images are without cacheBusterID and some of them are repeated and they have cacheBusterID. So what I did basically have XML data with 1.jpg, 2.jpg, 3.jpg, 4.jpg, 5.jpg and they're repeated for 5 times for example. As you can see in attachement from my firebug the last one without any auditSize and cacheBusterID. Please advice. Thanks.

[GreenSock]

That's what I tried to explain in the previous post - did you notice the "purpose=audit" in those URLs? Those are URLStreams that are for the sole purpose of auditing the file size. When you start loading a LoaderMax queue, it loops through its child loaders and if it finds any for which you didn't define an estimatedBytes, it will open a URLStream for a brief moment, requesting the file from the server. As soon as it receives a response from the server which allows it to determine the bytesTotal, it immediately closes the connection and moves on to the next one. It does NOT load the whole file. This makes progress reporting extremely accurate on the LoaderMax instance. I explain all of this in the docs and in the Tips & Tricks page at http://www.greensock.com/loadermax-tips/.

 

Originally I didn't append the cacheBusterID stuff on the URLStream audits but that was problematic because some browsers have a bug that causes them to mistakenly use the partially downloaded URLStream data when the full file gets requested, so files wouldn't properly load. Appending the cacheBusterID is absolutely necessary for audits in order to avoid this (and it kinda makes sense that you wouldn't want to cache your partial file download anyway).

 

See what I mean?

 

So it looks like LoaderMax is performing exactly as expected.

 

If you want to avoid the file size audits, that's easy. You can either define estimatedBytes for each of your loaders or you can just set auditSize:false on your LoaderMax instance. You can even set the static LoaderMax.defaultAuditSize = false to change the default value.

[droyde]

So I just wanted to confirm. Even though there's cacheBusterID on the URL and auditPurpose and I used noCache=false, that basically is equal to preloading the image with cache? just the same like loading image.jpg for over 5 times?

[GreenSock]

So I just wanted to confirm. Even though there's cacheBusterID on the URL and auditPurpose and I used noCache=false, that basically is equal to preloading the image with cache? just the same like loading image.jpg for over 5 times?

No, that is not correct. The audit is NOT LOADING THE WHOLE FILE. So for example, you could have a 20MB video - the audit may only load 0.0001MB of that file in order to find out how big it is. Then it stops, closes the NetStream, and moves on until all the files that don't have estimatedBytes defined are audited. Then it starts doing the actual full loading of the files. Basically all it needs for the audit is a single packet back from the server to determine the size (the total file size is indicated in the packet). So no, it is not the same as loading all your images 5 times.

 

Make sense now?

[droyde]

Cheers thanks jack. Make sense now. You're legend!

[Mika]

Is there a way to completely disable these extra params, even at the first request?

The files I try to load are dynamic and if the url hiting the server is diferent, a new file is generated even it's just for file audit.

Any advice would be appreciatted.

Thanks!

 

Oh my bad it was right there

 

LoaderMax.defaultAuditSize = false;

Edited October 25, 2012 by Mika