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. Unite 2023 Registrations are now LIVE! We are thrilled to announce that Unite 2023 Registration is now live and open for all!
    Dismiss Notice
New Forum User Notice Unite 2023 Registrations are now LIVE!

Second REST GET call fails

Discussion in 'WebGL' started by NickR2600, Feb 6, 2021.

  1. NickR2600

    NickR2600

    Joined:
    Aug 17, 2018
    Posts:
    20
    Hi everyone,

    I have a screen in may game that displays a heatmap. I make a REST GET call every 10 seconds to pull the latest data from a database. It's only about 500 bytes of data. The first GET call succeeds. The second GET call fails with this error message: Access to XMLHttpRequest at '<url>' from origin '<database>' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

    I don't think this message is accurate. Otherwise the failure would occur on the first GET call. And I made sure to set the allowed origins on the database.

    Unity is storing the results of the GET call within the indexedDB cache. Specifically, in UnityCache/XMLHttpRequest. This is occurring on Firefox and Chrome. Not sure if this matters, but the reponseHeaders' Last-Modified field is null.

    Funny thing, repeate GET calls work just fine in Firefox's incognito mode. In this case, the browser is reporting a convenient issue where the data can't be written to the indexedDB. Too bad it doesn't behave like this normally.

    I'm using Unity 2019.4.12f1. Does anyone know what's going on? Alternatively, is there a way to prevent data from REST calls from getting cached?

    Thanks
     
    NickR2600, Feb 6, 2021
    #1

  2. jukka_j

    jukka_j

    Unity Technologies

    Joined:
    May 4, 2018
    Posts:
    944
    Try using the Firefox/Chrome Network tab in Devtools to debug what the network communication is that happens. Specifically what is different between the first two calls.

    The CORS block message comes directly from the browser, so if it is present, then there is certainly some cross-origin communication going on that the 3rd party server has not approved. (or there is a browser security bug)

    Double check the communication in the Network tab to see what the remote access is, and cross-reference it against the first succeeding one. Check both the Request side and the Response side headers. Then the difference will hopefully give a clue as to what is changing between the transfers.
     
    jukka_j, Feb 6, 2021
    #2

  3. NickR2600

    NickR2600

    Joined:
    Aug 17, 2018
    Posts:
    20
    Hi Jukka. Thanks for the advice. The response header stands out as a major difference between the two GET calls. Many fields are missing in the response from the second call, including 'Access-Control-Allow-Origin'. Since I know everything works in private browsing where the data isn't cached, I changed the response header to set 'Cache-Control' to 'no-store'. I don't know if this is a proper solution, but everything seems to work now.
     
    NickR2600, Feb 9, 2021
    #3

  4. jukka_j

    jukka_j

    Unity Technologies

    Joined:
    May 4, 2018
    Posts:
    944
    That sounds interesting. I wonder if the server has some kind of special behavior configured with respect to combination of CORS and caching. I can't recall Unity doing anything "nonstandard" on this front at least.
     
    jukka_j, Feb 10, 2021
    #4