- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Tue, 02 Apr 96 13:39:34 PST
- To: "David W. Morris" <dwm@shell.portal.com>
- Cc: HTTP Caching Subgroup <http-caching@pa.dec.com>
The Warning: header as proposed is insufficient to be useful. Each
warning header must be associated with the identity of the
proxy/server which created the warning. Without such
identification, it will be difficult or impossible for the user's
trouble/help desk to do anything to resolve the cause of many
warning.
This was discussed at the LA meeting, and is "fixed" in the current
draft I'm trying to finish. I've appended the relevant section below,
for people to comment on. (Comments requested; flames ignored.)
I can't remember who came up with this suggestion first.
Would it be a violation of the spirit of HTTP to required an
ordered relationship between forwarded by: headers and warning:s?
That is, warnings must immediately follow the forwarded header
inserted by the proxy/server which issued the warning.
The Forwarded: header has been replaced by the Via: header, and
there is only supposed to be one Via: header (with perhaps multiple
items). I think this is probably more trouble than it's worth.
-Jeff
Warning headers are sent with responses using:
Warning = "Warning" ":" warn-code SP warn-agent SP warn-text
[SP language-tag [SP charset]]
warn-code = 2DIGIT
warn-agent = ( host [ ":" port ] ) | pseudonym
; the name or pseudonym of the server adding
; the Warning header, for use in debugging
warn-text = quoted-string
A response may carry more than one Warning: header.
The warn-text should be in a natural language and character set that
is most likely to be intelligable to the human user receiving the
response. This decision may be based on any available knowledge,
such as the location of the cache or user, the Accept-Language: field
in a request, the Content-Language: field in a response, etc. The
default language is English and the default character set is
US-ASCII.
Any server or cache may add Warning: headers to a response. New
Warning: headers should be added after any existing Warning: headers.
A cache MUST NOT delete any Warning: header that it received with a
response. However, if a cache successfully validates a cache entry,
it SHOULD remove any Warning: headers previously attached to that
entry. It MUST then add any Warning: headers received in the
validating response. In other words, Warning: headers are those
that would be attached to the most recent relevant response.
When multiple Warning: headers are attached to a response, the user
agent SHOULD display as many of them as possible, in the order that
they appear in the response. If it is not possible to display all of
the warnings, the user agent should follow these heuristics:
- Warnings that appear early in the response take priority
over those appearing later in the response.
- Warnings in the user's preferred language and character set
take priority over warnings in other languages or character
sets but with identical warn-codes and warn-agents.
- TBS
This is a list of the currently-defined warn-codes, each with a
recommended warn-text in English, and a description of its meaning.
10 "Response is stale"
MUST be included whenever the returned response is
stale. A cache may add this warning to any response,
but may never remove it until the response is known
to be fresh.
11 "Revalidation failed"
MUST be included if a cache returns a stale response
because an attempt to revalidate the response failed,
due to an inability to reach the server. A cache may
add this warning to any response, but may never
remove it until the response is successfully
revalidated.
12 "Caching may violate law"
SHOULD be sent with any response if the server is
aware of any law that specifically prohibits the
caching (including storage) of the response. This
may include copyright laws, confidential-records
laws, etc. Such responses SHOULD also be marked with
an expiration value in the past, and with a
"Cache-control: no-store" directive, to prevent an
unwitting cache from storing the value or returning
it in a cached response.
99 Miscellaneous warning
The warning text may include arbitrary information to
be presented to a human user, or logged. A system
receiving this warning MUST NOT take any automated
action.
TBS XXX anything else?
A note on warn-code 12, "Caching may violate law": some cache
operators may choose to configure their systems to ignore other
prohibitions on caching responses. Although this can reduce
semantic transparency, it is often appropriate for use with
network connections of limited performance or availability.
However, in unusual cases this behavior may violate civil or
criminal laws in some jurisdictions.
By sending this warning, an origin server puts on notice
regarding the legal situation. This may allow a cache operator
to avoid legal entanglements, and may also allow a server
operator to disclaim legal responsibility for improper caching.
It is not an HTTP protocol error to ignore this warning; doing
so may, however, subject a cache operator to legal action.
Similarly, it is not an HTTP protocol error to omit this
warning; doing so may, however, subject an origin server
operator to legal action.
Received on Tuesday, 2 April 1996 22:06:21 UTC