Issue with caching and WebGL builds 5.4+

Unity Engine
1

I have built my application several times and posted builds on the web, but since updating to Unity 5.4, my builds no longer work.

I was able to post a clean build earlier which worked, but after updating the files, I am getting the following:

This happens when I deploy to a web location, and even if I access the files directly from the origin, I am getting the error.

When attempting a local build using Build & Run, I get the following:

This happened during the 5.4 beta and I would have expected it to be fixed before being made stable.
Any advice?

2

Hello ahokinson.

This usually means that the UnityLoader.js version served from your server does not match the version of the .data file, served from the same server. Could you make sure that a fresh new build works well locally (without being uploaded anywhere)?

3

It does work with the caveat that the second mentioned error occurs.

4

How might I verify that these documents have the same version? If I can verify it’s a caching issue, I can track it down from there.

Thanks in advance for your help!

5

The easiest way to check if this is the issue, is to upload a fresh build to a new folder on your server (folder should have some random name which you have not used before). A new unique folder guarantees that the served files are not cached anywhere. Then open this new url in your browser to see if it makes any difference (I assume that your build works well when you run it from your local drive).
If this does not help, feel free to share your build url (here or privately).

6

Truth be told, this project is for a client whose entire business is based on smart caching. I should really have figured caching was an issue with them and not with Unity. I still get the error:

every time that I Build & Run locally, but if I click past it, it doesn’t affect the uploaded version.

Thanks for your help!

7

@alexsuvorov

I’m resurrecting this.

We turned off all caching and can verify that there is no caching happening. I am still receiving this error:

And when run locally, I receive the following error:

You can reproduce the issue at this URL:

http://tech.akamai.com/attack-globe/nightly/WebGL/

What else could this be? This seems to be an issue with 5.4. I am tempted to upgrade to 5.5b to see if that fixes the issue…

8

Hello ahokinson.
There is indeed a caching issue involved (or some files have not been updated on the server properly).
As you can see, your UnityLoader (http://tech.akamai.com/attack-globe/nightly/WebGL/Release/UnityLoader.js) expects a .data file of length 15350559, while the hosted file (http://tech.akamai.com/attack-globe/nightly/WebGL/Release/WebGL.data) is of size 15350877, which clearly indicates that those files are from different builds (i.e. if you download those files to your local drive manually, the local build wont run).

9

http://tech.akamai.com/attack-globe/nightly/CompletelyNewWebGL/

I guess you’re right…

This is a brand new folder and it seems to be working. I guess for now, this will be my workaround. Could you just briefly explain where you got those numbers from so I can investigate this further?

P.S. Really appreciate your help.

10

Normally it is sufficient to manually download the file in question though the browser address bar and compare it with its local version. But if you don’t have the original version, you can still tell with very high probability if the files come from the same build by comparing the .data offsets, which are hardcoded in the UnityLoader.js, and should look something like this for release build (somewhere near the end of the UnityLoader.js):

... new t(0,11128554,0,0).open("GET","/data.unity3d"),new t(11128554,11128573,0,0).open("GET","/methods_pointedto_by_uievents.xml"),new t(11128573,11156154,0,0).open("GET","/preserved_derived_types.xml"),new t(11156154,14447962,0,0).open("GET","/Il2CppData/Metadata/global-metadata.dat"),new t(14447962,15322934,0,0).open("GET","/Resources/unity_default_resources"),new t(15322934,15350559,0,0).open("GET","/Managed/mono/2.0/machine.config") ...

the 2 numbers specify offsets of the beginning and the end of the embedded file, while the very last offset should normally match the the end of the .data file, therefore should be normally the same as the uncompressed .data size (15350559 in your case). The uncompressed size of the .data file can be determined by simply decompressing it (it is a usual .gz archive).
In case of UnityLoader.js vs .data version mismatch you will most likely get the following error:
Uncaught Assertion failed: s_GlobalMetadataHeader->sanity == 0xFAB11BAF
as the embedded metadata file will most probably have a wrong offset.