This page is badly in need of an update.
My Guide to Web Authentication suggests that pages with login forms not be cached. If they are cached, it is possible re-login by going back to the form and resubmitting it.
Several HTTP headers effect caching. Most don't work as expected. This page represents an attempt to figure out how exactly to prevent caching. It is generated mostly from web gleanings and only a few personal tests. More of the latter are needed.
The prefered alternative is to send actual HTTP response headers. From a CGI program, this is easy. Just print them along with the Content-Type: header before printing the HTML portion of your document.
The following HTTP response headers are useful:
An expires directive with a date in the past will be recognized by most HTTP 1.0 browsers and proxies as an indication that the page should not be cached. If something other than a date is given on the Expires directive, it is normally taken to mean that the page expires immediately (HTTP 1.1 requires this, HTTP 1.0 only suggests it). I usually prefer the full date, but will mostly reference the shorter form for easy reference.
This is sufficient to convince Netscape 4.61 not to cache the page in disk or memory.
However, this apparantly will not prevent Internet Explorer from putting the page into its disk cache. Users will still be able to use the BACK and FORWARD buttons to access the copy in cache. However in most other situations where the user returns to the page it will be refetched from the server with a conditional "If-Modified-Since" request.
This is an HTTP 1.1 response header and will likely be ignored by HTTP 1.0 browsers and proxies.
Netscape 4.61 ignores this.
This entirely prevents Internet Explorer from caching the page to disk. BACK and FORWARD buttons will not work.
This is actually not supposed to be a response header at all. It's actually an HTTP 1.0 request header that is meant to tell proxy servers not to answer the request out of cache. However it is widely used in responses to request that the response not be cached.
Netscape 4.61 seems to treat this the same as Expires: 0, so it works fine.
Internet Explorer will honor this response header only on a secure https connection. Otherwise it is treated identically to Expires: 0.
It is possible to set some HTTP response headers using the HTML <META HTTP-EQUIV> tag. This is generally less effective. For one thing, they usually effect only browsers,not proxies. For another, they are often flakey. Usually these tags need to appear at the top of the HTML document in the <HEAD> section.
Works the same as the response header for Internet Explorer and Netscape.
Ignored by Internet Explorer version 4 and 5 and Netscape 4.61.
Sometimes works the same as the response header for Internet Explorer. However, at least some versions of Internet Explorer won't recognize it unless it is at the end of the document. The suggest that it be placed in the usual <HEAD> section, and then that it be repeated in a second <HEAD> section written at the end of the document, after the </BODY> tag and before the </HTML> tag. Ugh.
This apparantly does not work at all on Netscape 4.5 but it does on later and earlier versions.
Another way to keep the login form from begin resubmitted is to put the following directive on the <BODY> line of the page containing the form:
<BODY onLoad="document.forms[0].reset();">In Netscape 4.61 this causes the first form on the page (forms[0]) to be cleared whenever the page is reloaded, including when you go BACK to it. I haven't experimented with other browsers. It certainly won't work for browsers that don't support Javascript or for people who surf with Javascript turned off.