Hva om man heller satt opp en expire i html dokumentet eller i scriptet?
Setter man f.eks. denne til 01.01.1996 skal ikke browseren cache
dokumentet.
I fxlge RFC 1866 (pkt 5.2.5) kan man sette opp noe slikt i html
dokumentet:
<META HTTP-EQUIV="Expires" CONTENT="Mon, 01 Jan 1996 01:00:00 GMT">
Legger ved pkt 10.7 fra RFC 1945 og pkt 5.2.5 fra RFC 1866, samt URLen
til dokumentene:
10.7 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.
...og RFC 1866 pkt 5.2.5:
The <META> element is an extensible container for use in identifying
specialized document meta-information. Meta-information has two main
functions:
* to provide a means to discover that the data set exists
and how it might be obtained or accessed; and
* to document the content, quality, and features of a data
set, indicating its fitness for use.
Each <META> element specifies a name/value pair. If multiple META
elements are provided with the same name, their combined contents--
concatenated as a comma-separated list--is the value associated with
that name.
NOTE - The <META> element should not be used where a
specific element, such as <TITLE>, would be more
appropriate. Rather than a <META> element with a URI as
the value of the CONTENT attribute, use a <LINK>
element.
HTTP servers may read the content of the document <HEAD> to generate
header fields corresponding to any elements defining a value for the
attribute HTTP-EQUIV.
NOTE - The method by which the server extracts document
meta-information is unspecified and not mandatory. The
<META> element only provides an extensible mechanism for
identifying and embedding document meta-information --
how it may be used is up to the individual server
implementation and the HTML user agent.
Attributes of the META element:
HTTP-EQUIV
binds the element to an HTTP header field. An HTTP
server may use this information to process the document.
In particular, it may include a header field in the
responses to requests for this document: the header name
is taken from the HTTP-EQUIV attribute value, and the
header value is taken from the value of the CONTENT
attribute. HTTP header names are not case sensitive.
NAME
specifies the name of the name/value pair. If not
present, HTTP-EQUIV gives the name.
CONTENT
specifies the value of the name/value pair.
Examples
If the document contains:
<META HTTP-EQUIV="Expires"
CONTENT="Tue, 04 Dec 1993 21:29:02 GMT">
<meta http-equiv="Keywords" CONTENT="Fred">
<META HTTP-EQUIV="Reply-to"
content="fielding@ics.uci.edu (Roy Fielding)">
<Meta Http-equiv="Keywords" CONTENT="Barney">
then the server may include the following header fields:
Expires: Tue, 04 Dec 1993 21:29:02 GMT
Keywords: Fred, Barney
Reply-to: fielding@ics.uci.edu (Roy Fielding)
as part of the HTTP response to a `GET' or `HEAD' request for
that document.
An HTTP server must not use the <META> element to form an HTTP
response header unless the HTTP-EQUIV attribute is present.
An HTTP server may disregard any <META> elements that specify
information controlled by the HTTP server, for example `Server',
`Date', and `Last-modified'.
RFC 1866 finner man bl.a. pe:
http://www.cis.ohio-state.edu/htbin/rfc/rfc1866.html
og RFC 1945 pe:
http://www.cis.ohio-state.edu/htbin/rfc/rfc1945.html
-- I don't know the the key to success, but the key to failure is trying to please everbody --Bill Cosby