Updated (25/06/2010): Fixed typos in code example
Updated (16/11/2012): Fixed missing comma.
I have been working on a website recently and one of the pages on the site has a main functionality of showing dynamic results returned from a AJAX
call to a WCF service.
As I was developing and continuously testing with Firefox I was happy to see that my code was working well; based on the URL the results on the page will differ as expected.
However, When it came to test the page with Internet Explorer the results were dramatically different… No matter what the URL was the same content from my initial request kept appearing on the screen! Quickly enough I realized that it wasn’t something wrong with my code but with IE, after all in Firefox and Chrome it was working just fine.
So naturally, I googled for a solution and found this StackOverflow thread that confirmed to me that this was indeed an issue with IE. Unfortunately, the good answers there were only helpful to those who use jQuery to initiate the AJAX requests but I was using the proxy generated automatically by ASP.NET, so I had to find my own solution as I was unable to find anything useful online.
Below are ways you can use to fix the problem. First, I’ll show how to fix it when using the MS Service Proxy and then how to fix it when using jQuery.
Microsoft Service Proxy
If you’re interested in seeing how to make use of the auto-generated service proxy in your AJAX calls you can refer to an earlier article I wrote a while back: Tying in WCF, JSON and jTemplates.
Unlike jQuery when using the proxy we are another level apart from the actual plumbing code of issuing the request so its not as easy to modify the URL or change some kind of caching property, the proxy does the calling for us and it is generated automatically so making changes to it (not that it would be a good idea) is not readily available to us.
So how can we workaround the problem? The good folks at Microsoft have given us a hook point in the form of an event that is just the right place to intervene.
Here is the code you can use to make sure Explorer will actually issue a new request and not just use data it cached:
function _onServiceRequestInvoke(sender, networkRequestEventArgs)
var now = new Date();
var requestUrl = networkRequestEventArgs._webRequest._url;
var uniqueUrl = (requestUrl.indexOf(“?”) > -1 ? “&” : “?”) +
“nocache=” + now.getMilliseconds() + now.getSeconds() +
networkRequestEventArgs._webRequest._url = requestUrl + uniqueUrl;
What I did here was to add to every request URL that the proxy makes a unique (enough) parameter so Explorer thinks its a completely different request each time and doesn’t use any cached result.
The framework passes to our event handler (‘_onServiceRequestInvoke‘) method a collection of arguments of which one is the ‘_webRequest‘ which encapsulates the information needed to make the call to the server asynchronously. Naturally, one the web request object properties is the URL of the service operation which is being called. By modifying the URL, we trick Explorer to think its a different resource being called each time and so not to return a cached result.
Now we can continue happily making calls to the server without worrying about the browser our users use.
If you’re interested in learning how to make calls to a WCF service using jQuery refer to an earlier article I wrote: Creating a Webservice Proxy with jQuery
To fix the same caching problem when using jQuery to issue requests the good news are that its much easier and built into the jQuery library.
One way to disable caching altogether for all jQuery Ajax calls is by using the AjaxSetup function:
However, if you do want to have caching enabled for some calls and disabled for others you can change the cache setting per call using the Ajax function:
url: this._baseURL + method,
contentType: “application/json; charset=utf-8”,
What both approaches will do behind the scenes is actually modify the request URL with a unique parameter to ensure IE doesnt use a cached version.