Skip to main content

IE Caches a Lot

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:

if (req.xhr){
     return res.json(await this.usersData());
   }
   else {
     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:

$.getJSON('')

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.

Comments

Popular posts from this blog

Quick Deepstream.io Setup Using JSPM

Cross post from my employer's development blog: http://rootinc.github.io/2016/02/12/deepstream-jspm/
Want to use JSPM rather than Bower for running the Deepstream.io example? Follow these steps. This is basically a duplicate of the [Getting Started tutorial][tutorial] on the [Deepstream.io website][website] but using a really simple JSPM setup. This is a very crude guide where I list everything I had to do to get things running.

Create an empty project folder npm install deepstream.io Copy server code verbatim from the Getting Started guide jspm install npm:deepstream.io-client-js Hit enter for all the prompts from JSPM

We’re going to modify the client side code a little bit. We have native support for ES6 compiling with JSPM/Babel so we can import the Deepstream client directly:

import deepstream from 'deepstream.io-client-js'; let ds = deepstream( 'localhost:6020' ).login();

let record = ds.record.getRecord( 'someUser' );

let input = document.querySelector( 'inp…

Atari E3 2004 PAL digital press kit

Making note of some old swag. The Atari E3 2004 PAL digital press kit. See video for details.






Accessing other HTTP servers on Cloud 9 IDE

If you're using Cloud 9 to do development, you'll quickly realize that only ports 8080 through 8082 are available to the outside world from your development box. This is generally not an issue as you can set your application to bind to the $PORT environment variable when in development mode. However, there are sometimes other servers that we want to make use of that host on different default ports.

I recently had to setup a Neo4j server which defaults the admin interface of port 7474. Unfortunately, I could not access the admin interface even through the IDE based web browser window. So, what to do? I could change the default server settings so that it runs on a different port. However, the app I'm working on with a team has 7474 hard-coded and I currently don't feel like writing a local only work-around.

After some searching, I ran across a neat Linux tool called socat. This allows us to easily forward one port to another. After a quick install via apt-get, I ran the …