In general, browsers by default will attempt to store a local copy of information, such as web pages, images, etc., that is downloaded from a web server so that future requests for the same resource, does not require an additional trip back to the web server to download the same data.
In addition to web browsers, there may be other network equipment, such as proxy servers which are common on larger networks, that will perform the same function. While this may not be a bad thing for some data such as images, it is usually a bad thing when dealing with Ajax.
Internet Explorer is one of the browsers that tries to maximize its caching ability. If you have Ajax incorporated into your website, this may be an issue for users that access your website using a browser configured to cache information from the web server.
To prevent the browser from caching, you have several options. The most common approaches are as follows:
- Adding specificelements within thesection of your web page(s)Add a query string parameter with a random valueUse a POST instead of a GET RequestSend specific HTTP Response Headers to the browser
META
You may find other references on the Internet that suggest or recommend adding META elements to your web pages. My experience and analysis have found that this approach does not produce consistent results across all web browsers. I would not recommend this option
Random Query String
An interesting approach is to add a query string to the URL and add a random value to each Ajax request. Keep in mind that if you use this approach, you are sending unnecessary data to the web server since you are not going to process the query string parameter. In addition, you are not really solving the no-cache problem. You are actually caching each unique URL.
xhr.open(“GET”,"/ajax_load.aspx?x=" + Math.random(),true);
POST vs GET
Instead of sending your Ajax call as a GET, you can send it as a POST. According to section 9.5 in RFC 2616, responses to the POST method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields. So while you could configure a POST response to be cached, a response using POST will not be cached by the browser.
xhr.open(“POST”,"/ajax_load.aspx’,true);
HTTP Response Headers
Sending back specific headers to the browser is the best approach for most scenarios. In this case, when the web server sends an Ajax response back to the browser, it will send HTTP headers that instruct the browser to not cache the content. This approach appears to produce the most consistent results across the major browsers.
It is common to do this programmatically within your server-side scripts. The CacheControl is supported by an HTTP 1.1 standard while the Pragma header is from HTTP 1.0. We include various headers to ensure that various browsers are included in scope. The following code is specified in the web page that is proving the Ajax responses back to the requesting page.
ASP
<% Response.AddHeader “Cache-Control”, “no-cache” %> <% Response.AddHeader “Cache-Control”, “no-store” %> <% Response.AddHeader “Cache-Control”, “must-revalidate” %> <% Response.AddHeader “Pragma”, “no-cache” %> <% Response.AddHeader “Expires”, “Sat, 14 Jan 2012 01:00:00 GMT” %>
ASP.NET
Response.AppendHeader(“Cache-Control”, “no-cache”) Response.AppendHeader(“Cache-Control”, “no-store”) Response.AppendHeader(“Cache-Control”, “must-revalidate”) Response.AppendHeader(“Pragma”, “no-cache”) Response.AppendHeader(“Expires”, “Sat, 14 Jan 2012 01:00:00 GMT”)
