FAQ 3 - How to control remote browser cache

FAQ : Frequently Asked Questions

Q: How can I control from my CGIs the cache of a remote browser?
If an internet browser (Netscape, MS Internet Explorer, etc.) does use the cache, it is most likely that the next time this browser is requested to call a CGI, it shows the previous response instead of issuing a new request.
In such a case the user would see the cached response instead of the new one.
How can I control the way a remote browser uses its cache?
A: You have two ways to avoid that a browser fetches a previous version of a page from the cache, instead of asking a fresher version of a page to the remote server.

Technique 1- Avoid to cache a page
In your response html add a header that tells the browser not to cache the response.
To obtain this, start your response HTML in the following way:

/$top ***INITIAL SECTION
Content-type: text/html
Expires: 0

<HEAD>
<TITLE>...</TITLE>
</HEAD>
<BODY ... >
etc.

The header Expires ... is understood by any browser.
It means: "tell the remote browser that the contents of this page expire on Friday, January 1, 1999 at hours 00:00:00".
The browser would check the current date and time, determine that the page has expired, and therefore will not save it into its cache.

Technique 2- Make your response a unique page
Let's have an example.
Assume that some CGI of yours issues a response html containing the clickable sentence
Display customer John Smith's status
and that such sentence links to the following page

http://www.easy400.net/boatcgih/cussts.pgm?custno=000827

Let's see what happens when the user click on this sentence.
If the cache of your browser is active, your browser, before sending the request to the remote http server www.easy400.net, would check whether a page answering that same request is still in its cache.
If so, instead of issuing the request, the browser will pick that page from its cache, interpret it, and show it to you.
In this way, your browser saves you time and does not asks for a new duty to the remote http server.
By doing this, however, your browser does not guarantee that you see the lastest status of customer no. 000827.
What you can do to avoid the browser picking this page from its cache, is to make this page unique by making unique the response from your CGI.
Now suppose that your CGI, instead of providing the following link

http://www-922.ibm.com/boatcgih/cussts.pgm?custno=000827

provides a link somehow different, such as

http://www-922.ibm.com/boatcgih/cussts.pgm?custno=000827&TimeStamp=20000331223502

where 20000331223502 is the time stamp (date and time) when the CGI did answer.
You can bet that in the cache there is no page from such a request.
Therefore, when the user clicks on the sentence
Display customer John Smith's status
you may be sure that a fresh page is requested to the http server.
(By the way, though the example above is written for an <a href="...."> tag, you may use a similar technique in a <form ... > through a hidden field)
Which is better then, technique 1 or 2?
Technique 2, of course for the following reasons.
A)User going back pages.
If you used technique 1 in your CGIs, when the browser user goes back pages would send new requests to your http server. This would be slow, resource consuming and dangerous too (a previous order could be entered once more!).
If you used technique 2 in your CGIs, pages are fed back from the browser cache.
B)User requesting to print a page.
If you used technique 1 in your CGIs, the page is not in the cache, it is requested again to the http server. This would be slow, resource consuming and dangerous. We must also say that, if in your CGIs you used technique 1 and the POST method, pages cannot be printed.

JBP's solution
JBP likes technique number 2 (make your response a unique page), but prefers to use some JavaScript function to obtain the same result.

<html>
<head>
<script language="JavaScript">
function TS() {return Math.random();}
</script>
</head>
<body ....>
.... etc.

JBP case 1- Unique request in calling a CGI through a form. Assume you have an HTML page containing a form that invokes a CGI. You want to make sure that the CGI will be really invoked, with no chances to find the same invocation in the browser cash. To make unique the request from this form, you should dynamically generate a hidden input field with a timestamp value:

<form method=... action=...>
<script language=javascript>
document.write("<input type=hidden name=TimeStamp value=" + TS() + ">")
</script>
... etc.
</form>

JBP case 2- Unique request in calling a CGI through an anchor. Assume you have an HTML page containing a <A HREF=...> (anchor) that invokes a CGI:

To make this request unique, just code it as follow:

Note on JBP's JavaScript technique: If a static page contains some links, and you want these links to fetch all the times new pages from the server, you have got to use the JavaScript technique.
If the page containing such "unique" links is a dynamic page, you could have the timestamp values be generated as /%variables%/ from the CGI, or have them generated thru JavaScript (the latter is the technique I personally prefer).