ASP Response Object : CacheControl Property

The CacheControl property allows browsers and proxy servers to cache the output generated by Active Server Pages. This local copy on the browser or proxy server decreases perceived retrieval time for the end user (since they see the cached copy instead of requesting the same page again from the web server).

The CacheControl header can only be set to "Private" or "Public". The values for "Private" and "Public" are strings, and must be enclosed in quotation marks. By default, CacheControl is set to "Private". Pages with a "Private" header will not be cached by most browsers and proxy servers, while pages with a "Public" header will be cached.


  <% Response.CacheControl = "Private" %>  
  <% Response.CacheControl = "Public" %>

Tips & Hints

Enable Caching on Semi-Static Pages
Pages which do not need refreshing on every view can be safely cached by proxies and browsers, which in turn greatly reduces the load on your server. This is great if you have a news page which is only updated once every hour, or any other similar semi-static page.

Using a combination of Response.CacheControl and the Response.Expires or Response.ExpiresAbsolute properties, you can serve copies of that page to browsers and proxies which can then cache it until the next update. This reduces load on the web server and increases the perceived response time for the end user.

For our example of a news page which is updated once every hour, a viable solution would be to set the "Expires" header equal to one hour and enable caching. The following code does exactly that:

  Response.CacheControl = "Public"
  Response.Expires = 60
The Expires property's argument is in the form of minutes, so this code sets the cached page to expire sixty minutes in the future. This is a fast and easy way to cache pages, but there is a problem with it.

If we are updating our hypothetical news page at 11:00 AM, and a end user views and caches the page at 10:59 AM, then they will not refresh the page until 11:59 AM! Effectively, our caching solution places the end user an hour behind on our news updates, which is not the solution we wanted. However, we can easily work around this using VBScript's date functions (this could also easily be done in JavaScript).
Example workaround:

  Response.CacheControl = "Public"
  dim currentTime, currentMinutes, updateMinutes
  currentTime = Now()
  currentMinutes = DatePart("N", currentTime)
  updateMinutes = 60 - currentMinutes

  Response.Expires = updateMinutes
First we get the current time using the Now() function. We then get the minutes portion of the current time using the DatePart() function. "N" is a VBScript-defined argument to DatePart() which tells it to return the minutes portion of the date. Finally, we calculate the time remaining until the next update by subtracting the current minutes from sixty. For example, if the page is viewed at 10:42 AM, then 60 - 42 = 18. Response.Expires is then set equal to 18 minutes, so that the end user's cached copy will expire exactly at 11:00 AM1, and our update will be immediately available to them.

Forcing Refreshes
Although nearly all browsers will not cache pages with the "Private" CacheControl header set, there are a few non-standard ones that will. This could be a major problem, especially in the case of proxies. If a proxy caches a page and corresponding cookie, then another user viewing that page would view the cached page and the other user's cookie. This could give the second user access to the first user's shopping cart or personal information.

To ensure that a page is never cached by a browser, we can set the Response.Expires property to a negative number, which will disable caching. Always use a large negative number, to work around mismatches between the clocks on the server and on the end user's computer.

<% Response.Expires = -1000 %>

Back to the ASP Response Object
Back to ASP Objects
1 Actually, because we are only using minutes and ignoring the seconds, there is a possible error here of up to 59 seconds. This could be corrected, but for most purposes it is not a factor.


All code is my own (and is 100% hemp).

Log in or register to write something here or to contact authors.