Browser Cache Issues

[jimawe]

Hi All,

I wanted to give an update on recent changes to fix browser cache issues that many of us have experienced.  We've been slowly chipping away at optimizing how the content for the viewer gets downloaded and how we securely, but flexibly retrieve content from the cache.  It's over my head a bit so I won't try to give the full technical description, but I am developing apps just like you, so I know some of the issues you might run into and how to get around them.

1)  It has often been the case that you had to frequently clear the browser cache when upgrading to new versions of the viewer or switching between the same app deployed in different domains (e.g., localhost vs. a web domain).

2)  With a recent addition to the security/caching mechanism, we inadvertanly exposed a Cross-Origin problem with the static Viewer assets (materials and other supporting static content).  That change happened last week and some of you complained that your models stopped loading (I experienced the same thing).  Likely, you would have seen a message like the following:

This happened because the Viewer's static assets were being requested from two different domains.  If you were only running a single app that used the viewer, you might not have noticed the problem, but anyone running multiple apps (including someone else's sample app from this site), would likely have encountered the problem on the second app loaded.

** This problem has been fixed and you SHOULD be back to normal now.  Make sure to start with a clean browser cache just to make sure, but going forward, we shouldn't have to be so agressive about cleaning the cache.

There are two remaing problems you might run into in more advanced cases during development.

1)  If you try to retrieve the same URN for a model from two different apps, you will run into the same problem.  I have this case in my sample apps because I re-use the same models for a couple different samples, but it likely wouldn't happen in a real app.

2)  If you start up two different apps that have the same domain, but a different port number, you will still have a conflict.  This could happen if you are using an editor like Brackets that creates the web-server for your app to run in, and uses a different port for each app.

If you see an error like the following:

NOTE:  this looks like the previous error but it is failing when trying to load the URN for the model, not for the static assets of the viewer (as in previous case).

If this happens, just run each app in its own Chrome Incognito window (or clear the cache between loading of each app).  We will fix these two cases ASAP.

Please let us know if you observe any other issues like this so we know we've covered all the possible scenarios.  Sorry for the inconvenience...

JimA

[fpmalard]

Jim,

One thing concerns me. How we could provide an easier way for ordinary users to avoid this cache problem?

Websites often solve these problems with tricks like renaming the JavaScript file name, randomnly name image files, etc.

The operation of a browser cache cleanup seems too obvious for skilled people like us but could be something difficult for normal users (the main target of this simple Viewer technology). So if we can think about something like REFRESH or RELOAD button that can take care of these problems behind the scene that would be great.

Further, one of the potential usages of this technology is to share model modifications across different machines where users can work in a collaborative fashion. Do you see these cache/server problems in this scenario?

Regards,

Fernando Malard.

[jimawe]

Agreed.  The goal is to get to the point where a user never has to think about cleaning their cache.  That hasn't been the case during this beta version of the API, but we are getting better.  The recent fix should have cleared up those issues except for the two cases I outlined above.  If that is NOT the case and you are still having to clean your browser cache, then we have more work to do!  🙂

JimA

[Anonymous]

Hello,

I see two cases of caching issues as mentioned by Jim are still not fixed. The problem of Access-Control-Allow-Origin to see the same model in different domains is still there. Normal users will not know how to clear the browser cache if they don't see the model in the web viewer. Could you please let me know when it will fix.

Thank you.

[Anonymous]

Agreed, we have experienced the same issue with accessing the same model from different domains.  It requires clearing browser cache.

[Anonymous]

For example, if the user uses A360 site (https://a360.autodesk.com/viewer/) to view the model first. Later on, all other sites which use Autodesk View API will not work. Because resources loaded from the browser cache which have Access-Control-Allow-Origin = "https://a360.autodesk.com" will not load in another domain. Normal users have no idea why the developer site does not work. Whoever loads first will win the game. If the developer site loads first, A360 will not show any model.

Please see the below snapshot of the test on Google Chrome:

[fpmalard]

Same error happens if you try to run a local HTML (just opening the file into your browser) which opens with the URL starting with "file://..." and then try to access online resources such as Autodesk JavaScript APIs.

The JavaScript Extension samples could potentially present this issue if you try to run them locally:

https://github.com/Developer-Autodesk/library-javascript-viewer-extensions

For example, one of those samples performs a POST to "settoken" under Autodesk domain as follows:

var baseurl = "https://developer.api.autodesk.com";

// This is expected to set the cookie upon server response
// Subsequent http requests to this domain will automatically send the cookie for authentication

function setToken() {
    xmlhttp = new XMLHttpRequest();
    xmlhttp.open('POST', baseurl + '/utility/v1/settoken', true);
    xmlhttp.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
    xmlhttp.onreadystatechange = xmlHttpRequestHandler;
    xmlhttp.onerror = xmlHttpRequestErrorHandler;
    xmlhttp.withCredentials = true;
    xmlhttp.send("access-token=" + _accessToken);
}

Strangely the error message returned contains a reference to a Autodesk server folder called "C:\bubbles":

viewer3D.js?v=2.8:6195 XMLHttpRequest cannot load 

file:///C:/bubbles/dXJuOmFkc2sub2JqZWN0czpvcy5vYmplY3Q6Zm9yZ2VkZXZjb24yMDE2L0Nsb3NldDIwMTY3MTkxNjAxODYwNy5kd2c=. Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, https, chrome-extension-resource.ViewingService.rawGet @ viewer3D.js?v=2.8:6195

Could you guys at Autodesk elaborate about how these mixed scenarios should be properly handled and supported?

Regards,

[fpmalard]

Just tried to add the necessary Headers to avoid the CORS issue when running at localhost as follows:

xmlhttp.setRequestHeader('Access-Control-Allow-Origin', '*');
xmlhttp.setRequestHeader('Access-Control-Allow-Methods', 'GET,PUT,POST,DELETE');
xmlhttp.setRequestHeader('Access-Control-Allow-Headers', 'Content-Type');

The server responds (for any of the above added headers):

XMLHttpRequest cannot load https://developer.api.autodesk.com/utility/v1/settoken. Response for preflight has invalid HTTP status code 404

Any clue?

[Anonymous]

I think it is an easy fix for the Viewing Service, but it was not done for a long time. The CORS issue only happens for multiple domains to reuse same resources in the browser cache.

The Viewing Service just simply adds the query string that indicates the calling domain to the resource url of all links that have Access-Control-Allow-Origin pointed to this specific domain.

For example:

lmvworker.min.js?v=2.7*&domain=http%3A%2F%2Fapp.netonapp.com

Therefore, the added domain name will make the resource url to be specific only for this domain, not share to other domains and avoid the CORS issue. Please see the below snapshot for that missing query string:

 

[Anonymous]

Is there any update on this?  I have customers with multiple environments (DEV, QA, PROD) and each environment will load the same models, but with a different domain.  The CORS exceptions are bothersome.  Clearing browser cache or using a private window is not a great solution.  

[Anonymous]

I also need this issue to be fixed. The QA at Autodesk App Store also postpone to republish my app (.NETScript) for a long time because of this CORS issue. Many users on the Autodesk App Store don't know to get the updated version from the product website. The one at the App Store is outdated.

Thank you.