AJAX / RPC

Prevent IE Caching During Partial Page Updates

by Lonnie Lee Best

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.

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:

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:

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:

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.

Tell others aboutthis page:

facebook twitter reddit google+

About the Author

Lonnie Best has been using the internet since 1993, and has been making web pages since 1995. visit: http://www.lonniebest.com