Cross post from my employer's development blog: http://rootinc.github.io/2016/03/09/ie-caches/
In developing a page, I decided to do things a bit differently on the server. By doing an explicit check on the HTTP request headers, I can detect server-side if a request to the server is coming via XHR (Ajax) or a standard page load. I can then serve different content based on the request type. So, I can use the same URL for retrieving the initial HTML page and the raw JSON data associated with that page. Express makes this pretty easy:
return res.json(await this.usersData());
return res.view('users', await this.usersData());
I’m not sure if it’s technically more RESTful than having separate URL routes for data and HTML, but it felt like it made sense. The URL is referring to the same data, and based on a header, I want to determine how it is represented, but the data doesn’t change so why should the URL? This also makes it possible to do relative JSON requests, one less URL to statically track in the client:
All was working fine in Chrome, until I got reports that IE11 wasn’t loading the table on the page. The issue was rather difficult to track down. Refresh the page and the table rendered fine. Enter it in a tab or navigate to it, you got an empty table. Leave developer tools open to try and watch the network log, always worked.
Looking at logs, I noticed the data for the JSON request was coming back sort of undefined1. Trying to debug with Fiddler, it appeared that a second request to `/users` for the JSON data was not happening. I didn’t get direct results when Googling this, but there were plenty of mentions of IE’s aggressive caching policies. I switched my jQuery code to use the option `cache:false`, which ensures a unique URL for every JSON request thus forcing IE to not cache. Bingo! Everything is working fine now.
What if though, I merely used a slightly different URL than what was present in the location bar in the browser. It would be less aggressive than `cache:false`. So I added a random query variable `$.getJSON(‘/users?_blah’)`. This also works.
I didn’t take the time to look at the underlying XHR objects, but my assumption here is that IE is caching the browser’s request to `/users` and then trying to use the response from that (which is HTML) for subsequent XHR requests for the same URL. This sort of makes sense in an ultra efficiency sense, but at least for this case, it should perhaps key the cache with a few of the request headers. Not sure if that’s what Chrome does or if it’s just really lax on caching.
Note I also tried `$.getJSON(‘/users’)` explicitly but it had the same cached effect as just using the empty string.
*1* The results in the IE console from logging on the returned data were rather confusing, but obviously not usable. The object would return with property names and list array lengths but show undefined with regards to values as I drilled down. How it got the structure but not the content I am not sure.