AJAX / RPC

Prevent IE Caching During Partial Page Updates

This article is intended for web developers who use remote procedure calls (RPC | Remoting | AJAX) to update portions of a webpage without having to reload the entire web page. Specifically, this article deals with a method I used to overcome the obstacle of Internet Explorer's browser-side caching of "javascript initiated" partial page updates.

The Problem:
Browser Caching in Internet Explorer Is Preventing Real-Time Data

While creating a web application that uses remote procedure calls, I ran into a problem; I would click a link that was suppose to update the content of a markup element (on the webpage), and instead of updating that element with the latest data from the web server, it would instead display a stagnant copy that the browser previously cached. This behavior occurred in the Internet Explorer 6.0 web browser, while the Firefox web browser worked as I expected.

The Specifics:
How Internet Explorer's Browser Caching Works during RPC

When your web page uses Javascript to update the content of a markup element, Internet Explorer looks at the web address of that remote procedure call very closely. If the address exactly matches an address that has been previously "RPCed", it will return the cached copy of that request from the browser (rather than downloading a fresh copy from the web server).

The Workaround:
Make Your Remote Procedure Calls Have an Unprecedented URL

Did you know that you that you can use multiple URLs to get to the exact same web resource? The following URLs, although different, go to the exact same web page:

• http://www.lonniebest.com/Music/?key=PleaseTakeMeElsewhereThisGuyIsCrazy
• http://www.lonniebest.com/Music/?key=WhoIsThisNut

By changing the query string portion of the URL, we change the URL, but we don't necessary change the web resource that handles the request. Internet Explorer won't return a cached version of a page if the entire URL is technically different. So you can prevent IE from caching by ensuring that each remote procedure call has a URL that has not been previously requested. Specifically, by adding an unprecedented key/value pair to the query string portion of the URL, IE will request fresh data from your web server (and your web server will simply ignore the unprecedented key/value pair). So how do you ensure the URL is unprecedented? Use javascript's time functions to add an unprecedented key/value pair to the query string's key/value collection.

Example

If your remote procedure call needs to get:

http://www.yourdomain.com/?id=47

Add an unprecedented key/value pair to the query string portion of the URL:

http://www.yourdomain.com/?id=47&ms=

The number on the end of this URL represents the number of milliseconds that have occurred since the beginning of the first day in 1970. This will do a pretty decent job of ensuring the URL will be unprecedented (from IE's perspective) each time the user clicks. Here's the javascript:

var url = "http://www.yourdomain.com/?id=47" + "&ms=" + new Date().getTime();

Server Side Problems:
Server.Transfer versus Request.Redirect

If your web application implements server side redirects be sure you understand what is going on during these redirects. When I first got done implementing the technique described in this article, I had a few partial page updates that were still being cached by Internet Explorer.

It turns out, that when my web application would implement a server side redirect (during a partial page update request), my web server would send the browser the URL of the redirected resource, and then (if it wanted to) the browser would make another request for the redirected URL. Since the redirected URL didn't have an unprecedented key/value pair, the browser served its cache rather than requesting the redirected URL from the server.

Rather than making the server-side redirect URLs unprecedented, I chose to implement a "server transfer", rather than a "request redirect". A "server transfer" doesn't tell the browser that you are sending it data from another web resource than the browser originally requested. It simply sends the redirected page to the browser without informing the browser that it has been redirected. If you use ASP.net, here's an article that describes the differences between these methods:

http://www.csharpfriends.com/Articles/getArticle.aspx?articleID=15

I'm sure PHP and others have equivalents to the .Net methods I've mentioned, so find out how your implementation handles it so that you can be sure to retrieve real-time data with your remote procedure calls.

Comments? Questions? Email Here

© HowtoAdvice.com

How to Advice .com