How to disable cache-breaking string

#1

I was having a hard time trying to cache my HTML5 app and realized a big part of this was because the code is throwing random numbers to prevent caching. Relevant topic: Assets overwriting, dead resources and cache buster

I went on the produced .js file and commented that out, making it always go for the regular file, without parameters, and my app works flawlessly now. By looking at the source code that’s referenced on the topic above, it doesn’t look like I’m able to make my app not use that trick… which means every time I compile it I’ll have to make the changes.

Am I correctly assessing the situation?

Thanks.

#2

Open your copy of Lime, find Preloader.hx, and edit this line:

I’m not sure if you also need to edit line 84.

#3

Thank you, that makes things easier. By the way, yes, I had to edit both lines on my project for it to work.

#4

Sorry for the delay, what is the purpose of not having a cache string?

The cache string is used once per compile, this means that one version of your application should cache, but new versions should break the cache. This might be an ideal balance between keeping the cache when revisiting (unlike a random cache break string) and no cache breaking at all (which won’t deal with updated files with the same name)

What do you think?

#5

For some reason we were not being able to load a cached version of an app when the cache string was present. I was debugging via Safari and it would ask for a different file when I simply reloaded it…

#6

I like the idea in principle that the cache string is created at compile time and used constantly for every download of that same build, but in my case, it seems to generate a new cache string every refresh of the page. See http://release.playsafesa.com/jenkins/cyanide/poker/betonline/master/release/web/staging/html5/bin/ which is a build made with openfl compile html5 -release

Any ideas why the cache string keeps changing?

#7

It seems it generates a new cache on start.

On lime Assets.hx, in the AssetCache class you can find

version = Std.int (Math.random () * 1000000);

There should be a way to disable this by configuration…

#8

Hi all,

I’ve fixed this issue - there are 2 pull requests waiting which make the caching controllable by the user.

[github]
lime/pull/729
openfl/pull/1130

1130 depends on 729, not sure what the procedure is for that case.
This allows for the current behavior if the user does not specify their own cache version, and better behavior if the user chooses to override it.

#9

Good call,

I think the intention was for this to be done once per compile-time, like a tiny macro call, so it caches per build of the application, not per run

#10

You could also use the build number as the cache version.

#11

Okay, tell me if this seems fine for you:

This should cache once per compilation, which was the original idea. Sorry this was breaking all caching, entirely :sweat_smile:

@player_03 that’s a good idea, but I wonder if someone might end up doing clean builds which delete the build number, so that the cache string would be the same every time.

#12

Looks good, but it could be a bit more readable. Instead of this:

return Context.makeExpr (version, Context.currentPos ());

You can use this:

return macro $v{version};
#13

@player_03 done, thank you

#14

Hi singmajesty,

I love your fix - it solves my original problem in a very intuitive way.

I was hoping to find some way of tracking your commit so that we can see exactly when your fix goes mainstream then we can use it in production?

Thanks for the great fix.