About gsCacheBusterID and purpose querystrings

[jancassio]

Hey,

 

I have a doubt about how to disable the gsCacheBusterID and purpose qs, in localhost these params is not be injected on url request, but when I change to a test environment or production, in all requests has these querystrings, even if I set noCache true and no add estimated bytes to the loader.

 

I have changed some _setRequestURL calls on LoaderItem to disable this by now, because in Safari, occurs lot of request erros and the plugin is disabled by browser.

 

Have is a clean way to avoid this?

[GreenSock]

If those parameters are injected into the url for local requests, Flash will throw errors (that has nothing to do with LoaderMax). That's why LoaderMax automatically omits them locally.

 

As for the gsCacheBusterID and purpose parameters, those are absolutely essential for file size audits because otherwise some browsers have bugs that cause them to use the partially-downloaded files as though they're finished which definitely isn't good, but I'm very confused about why you're saying that they're causing Safari to generate request errors and disable the Flash plugin. Could you provide a very simple example FLA (and any support files) that clearly reproduce this problem so that we can publish on our end and diagnose things? I've never heard of it before and many thousands of developers are using LoaderMax so I'm anxious to fix any issues that exist.

 

You are using the latest version of LoaderMax, right?

[jancassio]

Do not worry, it seems that the loadermax's okay:)

I talked to the admin webapp framework and it seems that it responded to the parameters sent, this caused a failure in the response and Safari blocked for security.

Already talked to him and soon it's will be resolved.

 

Thanks.

[sebastian]

Hi Greensock,

concerning your answer above: Do I see it right, that the gsCacheBusterId is appended to any image-load-request? (because in the documentation it says: noCache : Boolean - If true, a "gsCacheBusterID" parameter will be appended to the url with a random set of numbers to prevent caching ) - so I thought that it is only used when noCache is set to true.

 

Also it says: [new in version 1.89:] When you load() an ImageLoader, it will automatically check to see if another ImageLoader exists with a matching url that has already finished loading. If it finds one, it will copy that BitmapData to use in its own Bitmap in order to maximize performance and minimize memory usage.

But even in that case it requests the image with the gsCacheBusterId (says my firebug). Or is it, because I use the ImageLoader in a LoaderMax-Queue?

Thanks for your support.

[GreenSock]

the cache-busting stuff is ALWAYS added to file size audits because otherwise some browsers end up incorrectly using partially-loaded files from their cache and don't finish loading them (remember, the file size audits cancel themselves immediately as soon as they get a response from the server and can determine the overall size of the file). You can, of course, turn off file size audits either on an individual LoaderMax or on a more global basis using the LoaderMax.defaultAuditSize property. I'm pretty sure the stuff you're seeing is just the file size audits, but let me know if this doesn't answer your question adequately.

[sebastian]

exactly the answer I needed. thanks