In most cases, with ASP applications, browser cache is our enemy.
ASP pages are, by nature, dynamic. In contrast, HTML pages are static. A great deal of work in the Web arena has gone into improving the response time for HTML pages. Cache was designed to help solve this problem.
Page caching works beautifully for static HTML pages, but doesn't work well at all for ASP pages. ASP pages often change because the back-end content has changed or the content changes in response to user input. If the browser displays a cached page, the page may be out of date, or may not respond properly to user input. The ASP server-side code does not run because the proxy intercepts the request before it reaches your server. The Response object has several properties that can help solve this problem. However, there are some problems with these that you should be aware of.
Response.Expires and Response.ExpiresAbsolute
Two good methods with easy properties to use and understand. However, they don't work all the time. The problem doesn't lie within the commands themselves--they do add the proper header values to the response; it's that not all browsers act the way you might expect. Netscape browsers are particularly guilty of this improper behavior. Futhermore, even if a browser is honoring the content expiration, a proxy server within a corporate network may intercept the request and return a cached page from the proxy server. Proxy servers don't always honor the expiration date either. To force the proxy to request a fresh copy of the page, you can use the Response.CacheControl property.
Response.CacheControl
Set this to private to tell the proxy server NOT to cache the page. Most proxy servers will not cache pages if the CacheControl value is set to private.
Again, unfortunately not all proxy servers honor the CacheControl header either. With all of the uncertainty around who will and who will not honor response headers in web documents, ASP programmers have evolved a sure-fire method to force ASP page requests to refresh from the application server rather than from the cache or proxy server. That method involves changing the URL in some unimportant way for each request.
Here is what I do at the top of every ASP page in my application.
<%@ Language=VBScript %>
<% Option Explicit %>
<%
dim uUrl
uUrl = "uUrl=" & Date & Timer
%>
Then anywhere in my document where I am navigating to another page, I use that variable in the URL. Here are some examples of that.
<%
Response.Redirect "somepage.asp?ID=1422&" & uUrl
%>
<form action="somepage.asp?<%=uUrl%>">
<a href="somepage.asp?ID=1422&Search=find+me&<%=uUrl%>">
Because the date and time change constantly, the above method will append a unique string to the end of every URL reference in your application. Thus, the browser will be unable to locate it in cache.
The content in the FAQ is based on personal experience as well as many ASP references in my library. I use all of the methods above and have never had a single problem with caching in my ASP application.
Happy Caching
ToddWW
ASP pages are, by nature, dynamic. In contrast, HTML pages are static. A great deal of work in the Web arena has gone into improving the response time for HTML pages. Cache was designed to help solve this problem.
Page caching works beautifully for static HTML pages, but doesn't work well at all for ASP pages. ASP pages often change because the back-end content has changed or the content changes in response to user input. If the browser displays a cached page, the page may be out of date, or may not respond properly to user input. The ASP server-side code does not run because the proxy intercepts the request before it reaches your server. The Response object has several properties that can help solve this problem. However, there are some problems with these that you should be aware of.
Response.Expires and Response.ExpiresAbsolute
Two good methods with easy properties to use and understand. However, they don't work all the time. The problem doesn't lie within the commands themselves--they do add the proper header values to the response; it's that not all browsers act the way you might expect. Netscape browsers are particularly guilty of this improper behavior. Futhermore, even if a browser is honoring the content expiration, a proxy server within a corporate network may intercept the request and return a cached page from the proxy server. Proxy servers don't always honor the expiration date either. To force the proxy to request a fresh copy of the page, you can use the Response.CacheControl property.
Response.CacheControl
Set this to private to tell the proxy server NOT to cache the page. Most proxy servers will not cache pages if the CacheControl value is set to private.
Again, unfortunately not all proxy servers honor the CacheControl header either. With all of the uncertainty around who will and who will not honor response headers in web documents, ASP programmers have evolved a sure-fire method to force ASP page requests to refresh from the application server rather than from the cache or proxy server. That method involves changing the URL in some unimportant way for each request.
Here is what I do at the top of every ASP page in my application.
<%@ Language=VBScript %>
<% Option Explicit %>
<%
dim uUrl
uUrl = "uUrl=" & Date & Timer
%>
Then anywhere in my document where I am navigating to another page, I use that variable in the URL. Here are some examples of that.
<%
Response.Redirect "somepage.asp?ID=1422&" & uUrl
%>
<form action="somepage.asp?<%=uUrl%>">
<a href="somepage.asp?ID=1422&Search=find+me&<%=uUrl%>">
Because the date and time change constantly, the above method will append a unique string to the end of every URL reference in your application. Thus, the browser will be unable to locate it in cache.
The content in the FAQ is based on personal experience as well as many ASP references in my library. I use all of the methods above and have never had a single problem with caching in my ASP application.
Happy Caching
ToddWW
