STAR SYSTEMS ~ <META Http-Equiv="Pragma" Content="no-cache">

Prevent the browser from Caching a page

This page is an explanation of using the Meta tag to prevent caching, by browser or proxy, of an individual page wherein the page in question has data that may be of a sensitive nature as in a "form page for submittal" and the creator of the page wants to make sure that the page does not get submitted twice.

HTTP is a data access protocol currently run over TCP and is the basis of the World Wide Web.

cache:
      A program's local store of response messages and the subsystem
      that controls its message storage, retrieval, and deletion. A
      cache stores cachable responses in order to reduce the response
      time and network bandwidth consumption on future, equivalent
      requests. Any client or server may include a cache, though a cache
      cannot be used by a server that is acting as a tunnel.

Update on this, M.S. just had to do things differently.
Just put the following between the <head> and </head>

that will do it.. IE needs the expires. View source of this page for example.

Further Update on this, M.S. messed up badly.
http://support.microsoft.com/support/kb/articles/Q222/0/64.ASP?LNG=ENG&SA=AL
kinda funny page there. They recommend you put another head meta and /head at the end of the doc after /body. I do not recomend anyone do what they say, it is totally non sensical and will break netscape and other versions of browsers..

All the gory details...

Just place this line: <META Http-Equiv="Pragma" Content="no-cache"> between the <head> and </head> lines on your page. This makes it so that when you are returned the browser says "ahh, I cannot cache this page, I must request it again from the server". And the new page you see is the updated page without hitting "reload" after. You can use the "Expires" tag with old dates, say 1995 to do the same thing however it will also prevent Search engines from indexing the page if the date is too far in arrears. Even though it is not proper re: the IETF, it is better to do <META Http-Equiv="Expires" Content="0"> using "0" for the date. This will signify that the date is invalid therefore it is not cachable.

Note: I do not de-cache my guestbook nor my links page, as below, anymore because it causes too much extra traffic to the site. I am using over 17 gigs a month now as it is.

The best advice now with the problems of IE since v5 is you can only decache POST and not GET. IE does not honor decaching a GET

If a person hits the back button, 90% of the time (depends on browser compatibility and to some extent the server) the page in question would not be cached. This is a more universal solution than using Javascript for the same function, JS is only compatible with about 50%, at most, of the browsers out there. It is also very hard to write compatible JS because of the very many changes and variations to the language.

A more bullet proof way to do it would be to make it return the new updated data on the same page, as in my Links page example, thus trashing any form data that was there before. If they hit the back button after the transaction then they are where they were before the form for the transaction. For the other 10% of the browsers, if you must, Put a note "Hit reload if page is not updated automatically after you do the submit" thus the user would cause the original data to expire themselves. The same page update is easy to do with Cgi/Perl, in essence you need to be able to generate dynamic pages, the first page a browser would see is the form page, after a submit the Cgi would dynamically update that same page with the new data.

The fact that some pages may be in frames have nothing to do with it, they are referenced by actual Urls and this same trick can be applied to them as well.

How all this will be implemented in regards to the META Http-Equiv tag is another matter. I can find no one source on it where there is a governing body, it is not well documented and very hard to find any comprehensive info on it anywhere. Mostly all you can find is "content type, name, keywords and description" pages, little to none on "http-equiv" and it's variants. A search of the W3.ORG site on "META" or "http-equiv" turns up nothing and a search on the WDVL - Stars.com returns practically nothing and nil in regards to Pragma or cache. Similarly Search.Netscape.com turns up very little relevant info likewise Netscape World with the keys of "Meta" turns up too many pages to check and "http-equiv" returns 11 irrelevant pages on the subject. The Verity Internet Virtual Library was of not much help either.

I searched the net exhaustively and came up with but one site that has a somewhat comprehensive listing of Meta tags, that site is Vancouver-Webpages.com however their explanation of "Pragma" Content="no-cache" is too brief to be of much use but you already have the details above anyway.

The full Http 1.0 specification is here. Study that spec., untold powers are hidden in it. Figuring out how to utilize them is another matter..

Excerpts from the Http 1.0 specification are as follows:

PRAGMA

The Pragma general-header field is used to include implementation-specific
directives that may apply to any recipient along the request/response chain.
All pragma directives specify optional behavior from the viewpoint of the
protocol; however, some systems may require that behavior be consistent with
the directives.

       Pragma           = "Pragma" ":" 1#pragma-directive

       pragma-directive = "no-cache" | extension-pragma
       extension-pragma = token [ "=" word ]

When the "no-cache" directive is present in a request message, an application
should forward the request toward the origin server even if it has a cached
copy of what is being requested. This allows a client to insist upon receiving
an authoritative response to its request. It also allows a client to refresh a
cached copy which is known to be corrupted or stale.

Pragma directives must be passed through by a proxy or gateway application,
regardless of their significance to that application, since the directives
may be applicable to all recipients along the request/response chain. It is
not possible to specify a pragma for a specific recipient; however, any
pragma directive not relevant to a recipient should be ignored by that recipient.

EXPIRES

The Expires entity-header field gives the date/time after which the entity
should be considered stale. This allows information providers to suggest
the volatility of the resource, or a date after which the information may
no longer be valid. Applications must not cache this entity beyond the date
given. The presence of an Expires field does not imply that the original
resource will change or cease to exist at, before, or after that time.
However, information providers that know or even suspect that a resource
will change by a certain date should include an Expires header with that
date. The format is an absolute date and time as defined by HTTP-date in
Section 3.3.

       Expires        = "Expires" ":" HTTP-date

An example of its use is

       Expires: Thu, 01 Dec 1994 16:00:00 GMT

If the date given is equal to or earlier than the value of the Date header,
the recipient must not cache the enclosed entity. If a resource is dynamic
by nature, as is the case with many data-producing processes, entities from
that resource should be given an appropriate Expires value which reflects
that dynamism.

The Expires field cannot be used to force a user agent to refresh its display
or reload a resource; its semantics apply only to caching mechanisms, and
such mechanisms need only check a resource's expiration status when a new
request for that resource is initiated.

User agents often have history mechanisms, such as "Back" buttons and history
lists, which can be used to redisplay an entity retrieved earlier in a session.
By default, the Expires field does not apply to history mechanisms. If the
entity is still in storage, a history mechanism should display it even if the
entity has expired, unless the user has specifically configured the agent to
refresh expired history documents.

      Note: Applications are encouraged to be tolerant of bad or misinformed
      implementations of the Expires header. A value of zero (0) or an invalid
      date format should be considered equivalent to an "expires immediately."
      Although these values are not legitimate for HTTP/1.0, a robust
      implementation is always desirable.

Looking deeper into things I see that the new HTTP 1.1 spec., in regards to the caching problem, is only keeping the Pragma directive for backwards compatibility and has added to it a new directive called "cache-control" which is much more powerful and comprehensive with many variations to it.

The intent of the IETF and the W3 is to implement HTTP 1.1 as soon as possible. The specification solves many long standing problems with the HTTP 1.0/0.9 spec. It also provides for a much more robust means of transferring data along a TCP channel thereby helping to alleviate the current Internet congestion problems we all see. "Some of the benefits (and necessity to implement) persistent connections and pipelining to achieve superior performance using HTTP/1.1; This results in a large savings in number of packets, substantial savings elapsed time"

Because of this intention and the fact that all common Server daemons are being updated to reflect the changes in the new spec., you should be aware of the following changes and additions in regards to Caching. They recommend "Clients should include both header fields when a "no-cache" request is sent to a server not known to be HTTP/1.1 compliant.". In essance they are recommending that a webmaster should include the newer directive "cache-control" at all times and if you are not sure of the server being 1.1 compliant then include the other (pragma / expires) also. I would recommend using the older directive and if it ever quits working (which it should not) then add a newer one also.

The specification is tough to read and very convoluted especially in regards to "Caching" because one of the prime factors in the new spec. is to provide robustness which goes hand in hand with Caching therefore there is a lot more on caching in the spec. About 40-50 pages now. The new spec. is also 161 pages long vs. 59 pages for the 1.0 spec. Also the spec. is just now going through the final phase so changes are entirely possible therefore I am only going to include the actual verbiage, relevant to our discussion here, until the spec. is finalized.

What follows is just the pertinant part of the new spec in regards to disabling cache. There is about 30 more pages related to Caching but most all that is for the die hard programmer writing servers and proxys.

14.32 Pragma

   The Pragma general-header field is used to include implementation-
   specific directives that may apply to any recipient along the
   request/response chain. All pragma directives specify optional
   behavior from the viewpoint of the protocol; however, some systems
   MAY require that behavior be consistent with the directives.

          Pragma            = "Pragma" ":" 1#pragma-directive

          pragma-directive  = "no-cache" | extension-pragma
          extension-pragma  = token [ "=" ( token | quoted-string ) ]

   When the no-cache directive is present in a request message, an
   application SHOULD forward the request toward the origin server even
   if it has a cached copy of what is being requested. This pragma
   directive has the same semantics as the no-cache cache-directive (see
   section 14.9) and is defined here for backwards compatibility with
   HTTP/1.0.  Clients SHOULD include both header fields when a no-cache
   request is sent to a server not known to be HTTP/1.1 compliant.

   Pragma directives MUST be passed through by a proxy or gateway
   application, regardless of their significance to that application,
   since the directives may be applicable to all recipients along the
   request/response chain. It is not possible to specify a pragma for a
   specific recipient; however, any pragma directive not relevant to a
   recipient SHOULD be ignored by that recipient.

   HTTP/1.1 clients SHOULD NOT send the Pragma request-header. HTTP/1.1
   caches SHOULD treat "Pragma: no-cache" as if the client had sent
   "Cache-Control: no-cache". No new Pragma directives will be defined
   in HTTP.


14.9 Cache-Control

   The Cache-Control general-header field is used to specify directives
   that MUST be obeyed by all caching mechanisms along the
   request/response chain. The directives specify behavior intended to
   prevent caches from adversely interfering with the request or
   response. These directives typically override the default caching
   algorithms. Cache directives are unidirectional in that the presence
   of a directive in a request does not imply that the same directive
   should be given in the response.

     Note that HTTP/1.0 caches may not implement Cache-Control and may
     only implement Pragma: no-cache (see section 14.32).

   Cache directives must be passed through by a proxy or gateway
   application, regardless of their significance to that application,
   since the directives may be applicable to all recipients along the
   request/response chain. It is not possible to specify a cache-
   directive for a specific cache.

          Cache-Control   = "Cache-Control" ":" 1#cache-directive

          cache-directive = cache-request-directive
                          | cache-response-directive

          cache-request-directive =
                            "no-cache" [ "=" <"> 1#field-name <"> ]
                          | "no-store"
                          | "max-age" "=" delta-seconds
                          | "max-stale" [ "=" delta-seconds ]
                          | "min-fresh" "=" delta-seconds
                          | "only-if-cached"
                          | cache-extension

          cache-response-directive =
                            "public"
                          | "private" [ "=" <"> 1#field-name <"> ]
                          | "no-cache" [ "=" <"> 1#field-name <"> ]
                          | "no-store"
                          | "no-transform"
                          | "must-revalidate"
                          | "proxy-revalidate"
                          | "max-age" "=" delta-seconds
                          | cache-extension

          cache-extension = token [ "=" ( token | quoted-string ) ]

   When a directive appears without any 1#field-name parameter, the
   directive applies to the entire request or response. When such a
   directive appears with a 1#field-name parameter, it applies only to
   the named field or fields, and not to the rest of the request or
   response.  This mechanism supports extensibility; implementations of
   future versions of the HTTP protocol may apply these directives to
   header fields not defined in HTTP/1.1.

   The cache-control directives can be broken down into these general
   categories:

     o  Restrictions on what is cachable; these may only be imposed by the
        origin server.
     o  Restrictions on what may be stored by a cache; these may be imposed
        by either the origin server or the user agent.
     o  Modifications of the basic expiration mechanism; these may be
        imposed by either the origin server or the user agent.
     o  Controls over cache revalidation and reload; these may only be
        imposed by a user agent.
     o  Control over transformation of entities.
     o  Extensions to the caching system.

14.9.1 What is Cachable

   By default, a response is cachable if the requirements of the request
   method, request header fields, and the response status indicate that
   it is cachable. Section 13.4 summarizes these defaults for
   cachability. The following Cache-Control response directives allow an
   origin server to override the default cachability of a response:

public
  Indicates that the response is cachable by any cache, even if it
  would normally be non-cachable or cachable only within a non-shared
  cache. (See also Authorization, section 14.8, for additional
  details.)

private
  Indicates that all or part of the response message is intended for a
  single user and MUST NOT be cached by a shared cache. This allows an
  origin server to state that the specified parts of the response are
  intended for only one user and are not a valid response for requests
  by other users. A private (non-shared) cache may cache the response.

  Note: This usage of the word private only controls where the
  response may be cached, and cannot ensure the privacy of the
  message content.

no-cache
  Indicates that all or part of the response message MUST NOT be cached
  anywhere. This allows an origin server to prevent caching even by
  caches that have been configured to return stale responses to client
  requests.

  Note: Most HTTP/1.0 caches will not recognize or obey this
  directive.

14.9.2 What May be Stored by Caches

   The purpose of the no-store directive is to prevent the inadvertent
   release or retention of sensitive information (for example, on backup
   tapes). The no-store directive applies to the entire message, and may
   be sent either in a response or in a request. If sent in a request, a
   cache MUST NOT store any part of either this request or any response
   to it. If sent in a response, a cache MUST NOT store any part of
   either this response or the request that elicited it. This directive
   applies to both non-shared and shared caches. "MUST NOT store" in
   this context means that the cache MUST NOT intentionally store the
   information in non-volatile storage, and MUST make a best-effort
   attempt to remove the information from volatile storage as promptly
   as possible after forwarding it.

   Even when this directive is associated with a response, users may
   explicitly store such a response outside of the caching system (e.g.,
   with a "Save As" dialog). History buffers may store such responses as
   part of their normal operation.

   The purpose of this directive is to meet the stated requirements of
   certain users and service authors who are concerned about accidental
   releases of information via unanticipated accesses to cache data
   structures. While the use of this directive may improve privacy in
   some cases, we caution that it is NOT in any way a reliable or
   sufficient mechanism for ensuring privacy. In particular, malicious
   or compromised caches may not recognize or obey this directive; and
   communications networks may be vulnerable to eavesdropping.

14.9.3 Modifications of the Basic Expiration Mechanism

   The expiration time of an entity may be specified by the origin
   server using the Expires header (see section 14.21). Alternatively,
   it may be specified using the max-age directive in a response.

   If a response includes both an Expires header and a max-age
   directive, the max-age directive overrides the Expires header, even
   if the Expires header is more restrictive. This rule allows an origin
   server to provide, for a given response, a longer expiration time to
   an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This may be
   useful if certain HTTP/1.0 caches improperly calculate ages or
   expiration times, perhaps due to desynchronized clocks.

     Note: most older caches, not compliant with this specification, do
     not implement any Cache-Control directives.  An origin server
     wishing to use a Cache-Control directive that restricts, but does
     not prevent, caching by an HTTP/1.1-compliant cache may exploit the
     requirement that the max-age directive overrides the Expires
     header, and the fact that non-HTTP/1.1-compliant caches do not
     observe the max-age directive.

   Other directives allow an user agent to modify the basic expiration
   mechanism. These directives may be specified on a request:

   max-age
     Indicates that the client is willing to accept a response whose age
     is no greater than the specified time in seconds. Unless max-stale
     directive is also included, the client is not willing to accept a
     stale response.

   min-fresh
     Indicates that the client is willing to accept a response whose
     freshness lifetime is no less than its current age plus the
     specified time in seconds. That is, the client wants a response
     that will still be fresh for at least the specified number of
     seconds.

   max-stale
     Indicates that the client is willing to accept a response that has
     exceeded its expiration time. If max-stale is assigned a value,
     then the client is willing to accept a response that has exceeded
     its expiration time by no more than the specified number of
     seconds. If no value is assigned to max-stale, then the client is
     willing to accept a stale response of any age.

   If a cache returns a stale response, either because of a max-stale
   directive on a request, or because the cache is configured to
   override the expiration time of a response, the cache MUST attach a
   Warning header to the stale response, using Warning 10 (Response is
   stale).

14.9.4 Cache Revalidation and Reload Controls

   Sometimes an user agent may want or need to insist that a cache
   revalidate its cache entry with the origin server (and not just with
   the next cache along the path to the origin server), or to reload its
   cache entry from the origin server. End-to-end revalidation may be
   necessary if either the cache or the origin server has overestimated
   the expiration time of the cached response. End-to-end reload may be
   necessary if the cache entry has become corrupted for some reason.

   End-to-end revalidation may be requested either when the client does
   not have its own local cached copy, in which case we call it
   "unspecified end-to-end revalidation", or when the client does have a
   local cached copy, in which case we call it "specific end-to-end
   revalidation."

   The client can specify these three kinds of action using Cache-
   Control request directives:

   End-to-end reload
     The request includes a "no-cache" Cache-Control directive or, for
     compatibility with HTTP/1.0 clients, "Pragma: no-cache". No field
     names may be included with the no-cache directive in a request. The
     server MUST NOT use a cached copy when responding to such a
     request.

   Specific end-to-end revalidation
     The request includes a "max-age=0" Cache-Control directive, which
     forces each cache along the path to the origin server to revalidate
     its own entry, if any, with the next cache or server. The initial
     request includes a cache-validating conditional with the client's
     current validator.

   Unspecified end-to-end revalidation
     The request includes "max-age=0" Cache-Control directive, which
     forces each cache along the path to the origin server to revalidate
     its own entry, if any, with the next cache or server. The initial
     request does not include a cache-validating conditional; the first
     cache along the path (if any) that holds a cache entry for this
     resource includes a cache-validating conditional with its current
     validator.

   When an intermediate cache is forced, by means of a max-age=0
   directive, to revalidate its own cache entry, and the client has
   supplied its own validator in the request, the supplied validator may
   differ from the validator currently stored with the cache entry. In
   this case, the cache may use either validator in making its own
   request without affecting semantic transparency.

   However, the choice of validator may affect performance. The best
   approach is for the intermediate cache to use its own validator when
   making its request. If the server replies with 304 (Not Modified),
   then the cache should return its now validated copy to the client
   with a 200 (OK) response. If the server replies with a new entity and
   cache validator, however, the intermediate cache should compare the
   returned validator with the one provided in the client's request,
   using the strong comparison function. If the client's validator is
   equal to the origin server's, then the intermediate cache simply
   returns 304 (Not Modified). Otherwise, it returns the new entity with
   a 200 (OK) response.

   If a request includes the no-cache directive, it should not include
   min-fresh, max-stale, or max-age.

   In some cases, such as times of extremely poor network connectivity,
   a client may want a cache to return only those responses that it
   currently has stored, and not to reload or revalidate with the origin
   server. To do this, the client may include the only-if-cached
   directive in a request. If it receives this directive, a cache SHOULD
   either respond using a cached entry that is consistent with the other
   constraints of the request, or respond with a 504 (Gateway Timeout)
   status. However, if a group of caches is being operated as a unified
   system with good internal connectivity, such a request MAY be
   forwarded within that group of caches.

   Because a cache may be configured to ignore a server's specified
   expiration time, and because a client request may include a max-stale
   directive (which has a similar effect), the protocol also includes a
   mechanism for the origin server to require revalidation of a cache
   entry on any subsequent use. When the must-revalidate directive is
   present in a response received by a cache, that cache MUST NOT use
   the entry after it becomes stale to respond to a subsequent request
   without first revalidating it with the origin server. (I.e., the
   cache must do an end-to-end revalidation every time, if, based solely
   on the origin server's Expires or max-age value, the cached response
   is stale.)

   The must-revalidate directive is necessary to support reliable
   operation for certain protocol features. In all circumstances an
   HTTP/1.1 cache MUST obey the must-revalidate directive; in
   particular, if the cache cannot reach the origin server for any
   reason, it MUST generate a 504 (Gateway Timeout) response.

   Servers should send the must-revalidate directive if and only if
   failure to revalidate a request on the entity could result in
   incorrect operation, such as a silently unexecuted financial
   transaction.  Recipients MUST NOT take any automated action that
   violates this directive, and MUST NOT automatically provide an
   unvalidated copy of the entity if revalidation fails.

   Although this is not recommended, user agents operating under severe
   connectivity constraints may violate this directive but, if so, MUST
   explicitly warn the user that an unvalidated response has been
   provided.  The warning MUST be provided on each unvalidated access,
   and SHOULD require explicit user confirmation.

   The proxy-revalidate directive has the same meaning as the must-
   revalidate directive, except that it does not apply to non-shared
   user agent caches. It can be used on a response to an authenticated
   request to permit the user's cache to store and later return the
   response without needing to revalidate it (since it has already been
   authenticated once by that user), while still requiring proxies that
   service many users to revalidate each time (in order to make sure
   that each user has been authenticated). Note that such authenticated
   responses also need the public cache control directive in order to
   allow them to be cached at all.

14.9.5 No-Transform Directive

   Implementers of intermediate caches (proxies) have found it useful to
   convert the media type of certain entity bodies. A proxy might, for
   example, convert between image formats in order to save cache space
   or to reduce the amount of traffic on a slow link. HTTP has to date
   been silent on these transformations.

   Serious operational problems have already occurred, however, when
   these transformations have been applied to entity bodies intended for
   certain kinds of applications. For example, applications for medical
   imaging, scientific data analysis and those using end-to-end
   authentication, all depend on receiving an entity body that is bit
   for bit identical to the original entity-body.

   Therefore, if a response includes the no-transform directive, an
   intermediate cache or proxy MUST NOT change those headers that are
   listed in section 13.5.2 as being subject to the no-transform
   directive.  This implies that the cache or proxy must not change any
   aspect of the entity-body that is specified by these headers.

14.9.6 Cache Control Extensions

   The Cache-Control header field can be extended through the use of one
   or more cache-extension tokens, each with an optional assigned value.
   Informational extensions (those which do not require a change in
   cache behavior) may be added without changing the semantics of other
   directives. Behavioral extensions are designed to work by acting as
   modifiers to the existing base of cache directives. Both the new
   directive and the standard directive are supplied, such that
   applications which do not understand the new directive will default
   to the behavior specified by the standard directive, and those that
   understand the new directive will recognize it as modifying the
   requirements associated with the standard directive.  In this way,
   extensions to the Cache-Control directives can be made without
   requiring changes to the base protocol.

   This extension mechanism depends on a HTTP cache obeying all of the
   cache-control directives defined for its native HTTP-version, obeying
   certain extensions, and ignoring all directives that it does not
   understand.

   For example, consider a hypothetical new response directive called
   "community" which acts as a modifier to the "private" directive. We
   define this new directive to mean that, in addition to any non-shared
   cache, any cache which is shared only by members of the community
   named within its value may cache the response. An origin server
   wishing to allow the "UCI" community to use an otherwise private
   response in their shared cache(s) may do so by including

          Cache-Control: private, community="UCI"

   A cache seeing this header field will act correctly even if the cache
   does not understand the "community" cache-extension, since it will
   also see and understand the "private" directive and thus default to
   the safe behavior.

If you have any information to add to this page or comments / criticisms please send me an E-Mail

John R. Long - Star Systems - 818-344-9330