I recently created a very simple client-only (no server-side code) that loads needed data dynamically. In order to access data from another storage location (in my case the data came from a Windows Azure Blob), the application needed to make a choice: how to load the data.
It really came down to three choices:
- Load the data synchronously as the page loaded using an Inline script tag
- Load the data asynchronously as part of initial page load using JSONP
- Load the data asynchronously as part of initial page load using CORS
All 3 options effectively work within the Same Origin Policy (SOP) sandbox security measures that browsers implement. If access is not coming from a browser (but from, say,
curl or a server application), SOP has no effect. SOP is there to protect end users from web sites that might not behave themselves.
Option 1 would be to basically have a hardcoded script tag load the data. One disadvantage of this is put perfectly by Douglas Crockford: “A
</script> will block the downloading of other page components until the script has been fetched, compiled, and executed.” This means that the page will block while the data is loaded, potentially making the initial load appear a bit more visually chaotic. Also, if this technique is the only mechanism for loading data, once the page is loaded, the data is never refreshed, a potentially severe limitation for some applications; in the very old days, the best we could do was periodically trigger a full-page refresh, but that’s not state-of-the-art in 2014.
Option 2 would be to load the data asynchronously using JSONP. This is a fine solution from a user experience point of view: the page structure is first loaded, then populated once the data arrives. The client invokes the request using the
Option 3 would be to load the data asynchronously using CORS. This offers essentially the identical user experience as option 2 and also relies on the
callback) that simply returns a JSON object. The client making the call will then need to execute the function to get at the data. Option 1 has slightly more flexibility and could be simply a data structure declared with a known name like
var mapData = ... which the client can access directly.
JSONP is not based on any official standard, but is common practice. CORS is a standard that is supported in modern browsers and comes with granular access policies. As an example, CORS policies can be set to allow access from a whitelist of domains (such as paying customers), while disallowing from any other domain.
Summarizing CORS, JSONP, Inline
The following summary compares key qualities.
|Synchronous or Async||Synchronous||Async||Async|
|Granular domain-level security||no||no||yes||In any of the three, you could also implement an authorization scheme. This is above and beyond that.|
|Server support||full||full||partial||Servers need to support the CORS handshake with browsers to (a) deny disallowed domains, and (b) to give browsers the information they need to honor restrictions|
|Supported by a Standard||no||no||yes|
|Is it the future||no||no||yes||Safer. Granular security. Standardized. Max efficiency.|
Lessons Learned Using CORS
Yes, my simple one-page map app (described here) ended up using CORS. In large part since it is mature, and the browser support (see below) was sufficient.
Reloading Browser Pages: In debugging, CTRL-F5 is your friend in Chrome, Firefox, and IE if you want to clear the cache and reload the page you are on. I did this a lot as I was continually enabled and disabling CORS on the server to test out the effects.
Overriding CORS Logic in CHROME: It turns out that Chrome normally will honor all CORS settings. This is what most users will see. Let’s call this “civilian mode” for Chrome. But there’s also a developer mode – which you enable by running chrome with the chrome.exe –disable-web-security parameter. It was initially confused since it seemed Chrome’s CORS support didn’t work, but of course it did. This is one of the perils of living with a software nerd; my wife had used my computer and changed this a long time ago when she needed to build some CORS features, and I never knew until I ran into the perplexing issue.
Testing CORS from
curl: Helped by a post on StackOverflow, I found it very handy to look at CORS headers from the command line. Note that you need to provide SOME origin in the request for it to be valid CORS, but here’s the command that worked for my cloud-host resource (you should also be able to run this same command):
curl -H “Origin: http://localhost” -H “Access-Control-Request-Method: GET” -H “Access-Control-Request-Headers: X-Requested-With” -X OPTIONS –verbose http://azuremap.blob.core.windows.net/maps/azuremap.geojson
Browser Support for CORS
To understand where CORS support stands with web browsers, this fantastic site http://caniuse.com/cors offers a nice visual showing CORS support across today. A corresponding chart for JSONP is not needed since it works within long-standing capabilities.
My simple one-page map app is described here. That page includes a link to a running instance and its source code is easily viewed with View Source.
Pingback: Stupid Azure Trick #6 – A CORS Toggler Command-line Tool for Windows Azure Blobs | Coding Out Loud
Pingback: Stupid Azure Trick #7 – Use Windows Azure’s Local Storage Emulator with Web Sites | Coding Out Loud
Excellent article, well explained and where the virtues of both systems are in sight. I really clarified the situation, since I only used jsonp and jquery. With this article I aclré my doubts sovran CORS and see clearly the advantages of either method. Thank You