bokeh: [BUG] Potential Chrome CORS problem with local output

cc @jakirkham @canavandl @martey

Under certain circumstances, loading local HTML Bokeh output can result in the error:

Access to script at ‘https://cdn.bokeh.org/bokeh/release/bokeh-2.0.0.min.js’ from origin ‘null’ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.

The circumstance is this: BokehJS was previously first loaded from CDN without SRI/crossorigin attributes on the script tag, and then subsequently later, was loaded with them present. Evidently Chrome uses the cached headers and decides there is a mismatch. Steps to repro:

• clear cached images and files in chrome
• open a private window
• navigate to iris example in docs gallery
• run iris.py and open local iris.html file in a browser

When can this happen? For one, CDN loads in autoload_static were not fixed up in the last release, and still use “bare” script tags. So I think anyone who views our garllery first, then output_file output, will run in to this.

• A force-reload will fix and allow things to work (but a bad UX)
• Have not yet tested to see if other browsers are affected (but I don’t think so)

Certainly, we should fix up autoload_static ASAP so that gallery viewing does not instigate this for users. Should be easy and can go in a 2.0.1 next week.

But user generated output could also instigate this for viewers if the users use “bare” script tags in their Flask app or whatever. We don’t really have control over that.

Is there another fix or mitigation we can apply to make sure it always works, regardless? Would adding an crossorigin="anonymous" even to script tags without SRI hashes fix this? (I will try to test out later).

Thoughts welcome.

Some references:

• our AWS Cloudfront/S3 setup is as described here: https://www.boxuk.com/insight/enabling-cross-domain-access-in-cloudfront/

• WONTFIX issue in Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=67743#c17, specifically relevant:

  it is still possible to get the reported error when the response is cached (because the new CORS headers from the server are unknown to the browser when it retrieves the response from the cache). This is an open issue in the specification (https://www.w3.org/Bugs/Public/show_bug.cgi?id=23653). To work-around this problem as a user, just clear the browser’s cache.