In addition to a limited internal cache in the receiver, our servers cache all content that passes through to the receiver. This speeds the overall response for the user. The exceptions to this rule are:
These are three conditions where the servers do not cache content. In the instance where a secure protocol is used, the servers are by-passed altogether.
There may be a circumstance where the developer does not want the content to be cached (for example, where dynamic content is used). The most reliable way to keep pages from being cached by proxy servers is to alter the configuration files on the host server.
An alternative is to use tags to emulate HTTP headers. The problem with this method is that most proxies do not honor these directives so they are not widely used. Our proxy servers, however, do honor %u201Cno-cache%u201D directives given using the tag. There are several different ways of accomplishing this, and more than one can be used in a page. The following are some examples.
The most reliable method of ensuring that content is not cached is using the Expires attribute. The first is to set an expiration date in the past. This is an example:
<META HTTP-EQUIV="Expires" CONTENT="Thu, 01 Dec 1994 16:00:00 GMT">
Some sources give examples such as Content=%u201D0%u201D or something similar. This only works because most servers interpret anything other than a correct date as %u201Cin the past.%u201D Version 1.1 of the HTTP standard added a new field called Cache Control. One of the options for this attribute is %u201Cno-cache.%u201D The syntax is shown in the following example:
<META HTTP-EQUIV="Cache-Control" CONTENT="no-cache">
The tag attribute Pragma is another option, although it is technically incorrect for a server to send this to a client. The HTTP standard specifies %u201Cpragma%u201D as a header to be sent by clients when requesting a fresh copy of a page, not by servers. An example follows:
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
This method is unreliable and should be avoided.