Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. We have updated the language to the Editor Terms based on feedback from our employees and community. Learn more.
    Dismiss Notice
  3. Join us on November 16th, 2023, between 1 pm and 9 pm CET for Ask the Experts Online on Discord and on Unity Discussions.
    Dismiss Notice
New Forum User Notice Update to the Unity Editor Software Terms Unite 2023 - Ask the Experts Online

5.3 - Uncaught SyntaxError: Unexpected token <

Discussion in 'WebGL' started by Kmartin_ECS, Jan 11, 2016.

  1. Kmartin_ECS

    Kmartin_ECS

    Joined:
    Apr 15, 2015
    Posts:
    16
    I work for a simulation company, and we are working with a client on deploying a WebGL application with Scorm integration. Everything was functional when building on 5.2, but since 5.3 we are experience issues. We are able to run the application on our servers fine, but when the client tries to run it on their server, it won't run.

    The console info they are receiving is:

    ynchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check http://xhr.spec.whatwg.org/.
    ilias.php:65 Refused to set unsafe header "Accept-Charset"sendAndLoad @ ilias.php:65
    scormdriver.js:1230 Searching for SCORM 1.2 API
    scormdriver.js:1243 Found SCORM API, using SCORM
    scormdriver.js:1290 In InitializeExecuted, blnSuccess=true, strErrorMessage=
    scormdriver.js:1312 blnLoaded: true
    scormdriver.js:1354 IsLoaded: true
    scormdriver.js:1284 TouchCloud() failed.
    blob:https%3A//webaddress/a9c50b3c-4ceb-4e1e-b5c4-ca5411b2848b:1 Uncaught SyntaxError: Unexpected token <

    Since we are having no issues running it on our server, it has been difficult for us to troubleshoot. We believe their server is having trouble dealing with the WebGL compression that is forced in 5.3, and for some reason the Javascript fallback isn't kicking in. So far we have had them try the following:

    1. Deleting the .htaccess to try to force the javascript fallback decompression
    2. Moving .htaccess out of the Release folder up to the same level as index.html. Adding a RewriteBase line to .htaccess with a specific URL.
    3. Checking to make sure the url hosting has a valid SSL certificate.

    We are a bit stumped here, any ideas?
     
    Kmartin_ECS, Jan 11, 2016
    #1

  2. Marco-Trivellato

    Marco-Trivellato

    Unity Technologies

    Joined:
    Jul 9, 2013
    Posts:
    1,654
    Which type of server is it ?
     
    Marco-Trivellato, Mar 30, 2016
    #2

  3. Kmartin_ECS

    Kmartin_ECS

    Joined:
    Apr 15, 2015
    Posts:
    16
    They are running an Apache server on Windows, using Chrome as their only browser.

    Another thing I neglected to mention is that they are able to run the version we have hosted on our own server from their machines just fine as well. We have two identical 5.2 builds uploaded and packaged the same way. Those work on our own server and the client's server. We then have two identical 5.3 builds uploaded and packaged the same way, which work on our server and not on the client's, BUT the client can run the application from our server on their machines. So it seems the problem lies somewhere in the server configuration and some kind of incompatibility with the 5.3 files vs. 5.2.
     
    Kmartin_ECS, Mar 30, 2016
    #3

  4. Marco-Trivellato

    Marco-Trivellato

    Unity Technologies

    Joined:
    Jul 9, 2013
    Posts:
    1,654
    They could try to manually download jsgz, datagz and memgz files from the server and compare them to the original to see if there is any difference.

    Have you tried Unity 5.3.4 ?
     
    Marco-Trivellato, Mar 31, 2016
    #4

  5. Marco-Trivellato

    Marco-Trivellato

    Unity Technologies

    Joined:
    Jul 9, 2013
    Posts:
    1,654
    I forgot to mention that you should delete the .htaccess file when you do that.
     
    Marco-Trivellato, Mar 31, 2016
    #5

  6. Kmartin_ECS

    Kmartin_ECS

    Joined:
    Apr 15, 2015
    Posts:
    16
    We have tried Unity 5.3.4, same issue. I will try to have them compare the server files and check for a difference. Would they be looking for a difference in file size? Or actually running a diff against the content of the actual files?

    We created another test case today. We were able to get the application running on their LMS by using a Scorm Cloud dispatch (http://scorm.com/scorm-solved/scorm-cloud-features/control-your-content-with-dispatch/). The reason this worked is because the server the content is hosted on is a third party server, and the scorm dispatch just lets their LMS hook into it. However, this isn't an acceptable end-solution for them since the content needs to be hosted on their servers for security reasons. But it at least provides additional confirmation that the problem is something to do with their security configuration.
     
    Kmartin_ECS, Mar 31, 2016
    #6

  7. Marco-Trivellato

    Marco-Trivellato

    Unity Technologies

    Joined:
    Jul 9, 2013
    Posts:
    1,654
    both size and content should be the same.
     
    Marco-Trivellato, Mar 31, 2016
    #7

  8. Kmartin_ECS

    Kmartin_ECS

    Joined:
    Apr 15, 2015
    Posts:
    16
    Haven't been able to check content yet, but the sizes appear to be the same size as the package we upload to our third party server.

    Local file sizes (what Unity spits out and what we drop onto our internal server)
    datagz: 88,100KB
    jsgz: 5,448KB
    memgz: 401KB

    Zipped package file sizes (What we zip up to upload to third party server and to client)
    datagz: 90,214.097KB
    jsgz: 5,578.228KB
    memgz: 409.979KB

    Client's server package file sizes
    datagz: 90,214.097KB
    jsgz: 5,578.228KB
    memgz: 409.979KB
     
    Kmartin_ECS, Apr 1, 2016
    #8

  9. Kmartin_ECS

    Kmartin_ECS

    Joined:
    Apr 15, 2015
    Posts:
    16
    Hey Marco - sorry for the slow response. In addition to the file sizes being the same, I can now confirm the content is the same as well. I had them pull the files from their server and send them back to me, and I was able to upload them on our server and run the course just fine.
     
    Kmartin_ECS, Apr 20, 2016
    #9

  10. Kmartin_ECS

    Kmartin_ECS

    Joined:
    Apr 15, 2015
    Posts:
    16
    I also gave them a blank unity project with just a ground plane and the standard assets character controller, and it had the same issue.
     
    Kmartin_ECS, Apr 20, 2016
    #10

  11. alexsuvorov

    alexsuvorov

    Unity Technologies

    Joined:
    Nov 15, 2015
    Posts:
    327
    Hello Kmartin_ECS.

    Your answer clearly states that sizes are indeed different (90,214.097KB vs expected 88,100KB). Therefore the content can not be identical.

    The procedure is quite simple - if the loader does not recognize the downloaded files, then you can try to download them manually to check whether the server is configured correctly. If you just share the url of the content in question, your issue will be resolved easily. Otherwise you can try the following detailed procedure. Please keep in mind that there are many different ways to misconfigure a server, intentionally or not, so the following procedure may not cover all the possible cases.

    Step 1.

    Open the game url in the browser. Let it be yourdomain/yourfolder. Now use the View page source from the browser menu. Search the page source for the codeUrl: string. If the code url is relative (which is default, i.e. codeUrl: "Release/mygame.js") then append it to the game url above (i.e. yourdomain/yourfolder/Release/mygame.js).
    The code url extension in the page source should be .js as provided by the build system, otherwise upload the original build and try again.

    Step 2.

    Open the code url obtained above in the browser (i.e. yourdomain/yourfolder/Release/mygame.js).

    If you get 404 Not Found error, go to step 3.

    Otherwise the file might take quite a while to load. Then you should see JavaScript code starting with something like:
    Module["preRun"].push((function(){var unityFileSystemInit=Module["unityFileSystemInit"]||...

    If you do not see this code in the response and not getting 404 error either, then your server is configured incorrectly. Undo all the changes you have previously done related to the uploaded content and remove the yourdomain/yourfolder/Release/.htaccess file. Then go to Step 1, now you should be able to get 404 error for the code url.

    If your code is ok, then open dataUrl in the browser (i.e. yourdomain/yourfolder/Release/mygame.data) which should normally initiate its download. Open the downloaded .data file in a text editor (i.e. notepad, textedit etc) and you should be able to see it starting with:
    UnityFS 5.x.x ...

    Assuming the data file is ok, open the memUrl (i.e. yourdomain/yourfolder/Release/mygame.mem) in the browser. Open the downloaded .mem file in text editor and you should be able to see it starting with something like:
    ÿÿÿÿ ÿÿÿÿ ÿÿÿÿÿÿÿÿ ... or ˇˇˇˇ ˇˇˇˇ ˇˇˇˇˇˇˇˇ ...

    If your files look fine, go to Step 4, otherwise set your server configuration to default, remove the .htaccess file and try again.

    Step 3.

    If you got 404 error in Step 2, then open the codeUrl, dataUrl and memUrl in the browser with manually appended gz suffix (i.e. yourdomain/yourfolder/Release/mygame.jsgz, yourdomain/yourfolder/Release/mygame.datagz and yourdomain/yourfolder/Release/mygame.memgz). Those 3 files should normally get downloaded to the drive, where you can compare them with the files from the original build, the content should be identical (usually it is sufficient to just compare the file size).

    If the accessed urls with gz suffixes are not getting downloaded but instead are opened in the browser as text, then most probably your server is configured incorrectly, undo all the changes you have previously done related to the uploaded content and remove the yourdomain/yourfolder/Release/.htaccess file, then try again.

    Step 4.

    If the downloaded content looks ok but your game still does not launch, then there might be caching involved. Upload a fresh build to another folder with a random name which has not been used before and try again.

    If your urls are absolute (i.e. codeUrl: "anotherdomain/anotherfolder/Release/mygame.js") and are pointing to another domain or are using another protocol (i.e. you are trying to load resources via https while connecting to the main page via http), make sure you have properly configured the CORS headers on the referenced server.
     
    Last edited: Apr 21, 2016
    alexsuvorov, Apr 20, 2016
    #11

  12. Kmartin_ECS

    Kmartin_ECS

    Joined:
    Apr 15, 2015
    Posts:
    16
    Sorry I may have been unclear on this. When we are packaging up the course, it is compressed into a .zip folder along with the scorm package and anything else. When uploaded to the server, the package is unzipped and the uncompressed directory is created. When comparing our files vs. their servers, the unzipped files are identical in size, and the zipped files are identical in size. Meaning, our unzipped datagz is 88,100KB as is theirs.

    Regardless I will have them try the steps above. Unfortunately I cannot share the URL, I don't even have access to it due to their security.

    If it would help, I can provide the blank Unity project that we are also using to test. That way, you can see how we are packaging the course up with the scorm content.

    You should be able to download the test course here:
    https://drive.google.com/file/d/0BxIDx5z0LY-6U0pDa1V3eGIza2M/view?usp=sharing

    Again, this upload method and file hierarchy works for our server and third party servers, just not their server, so I don't expect to find anything useful in there. I am trying to get more details on their Apache and ILIAS configurations so that I can provide you guys with some more information.
     
    Kmartin_ECS, Apr 20, 2016
    #12

  13. alexsuvorov

    alexsuvorov

    Unity Technologies

    Joined:
    Nov 15, 2015
    Posts:
    327
    We are talking about the content being served from the server when you are performing a request.
    You should compare the files that you have downloaded manually from your browser address bar. Obviously, there is no zipping or unzipping involved here, as this is just downloading a file from a browser, as you normally do on any other website. So I am wondering why you have even mentioned the zipping in the first place.

    I understand that you can not share the url, but you should at least be able to access it yourself to perform the check, going through the steps above. Otherwise you will not be able to diagnose the issue with the server configuration or fix it.
     
    alexsuvorov, Apr 21, 2016
    #13