|FAQ : Frequently Asked Questions|
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:
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
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
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 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:
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:
If a static page contains some links, and you want
these links to fetch all the times new pages from