14.45 Warning
The Warning response-header field is used to carry additional
information about the status of a response which may not be reflected
by the response status code. This information is typically, though
not exclusively, used to warn about a possible lack of semantic
transparency from caching operations.
Warning headers are sent with responses using:
Warning = "Warning" ":" 1#warning-value
warning-value = warn-code SP warn-agent SP warn-text
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 intelligible 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 ISO-
8859-1.
If a character set other than ISO-8859-1 is used, it MUST be encoded
in the warn-text using the method described in RFC 1522 [14].
Fielding, et. al. Standards Track [Page 137]
RFC 2068 HTTP/1.1 January 1997
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 except as specified for specific Warning codes. 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:
o Warnings that appear early in the response take priority over those
appearing later in the response.
o Warnings in the user's preferred character set take priority over
warnings in other character sets but with identical warn-codes and
warn-agents.
Systems that generate multiple Warning headers should order them with
this user agent behavior in mind.
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 Disconnected operation
SHOULD be included if the cache is intentionally disconnected from
the rest of the network for a period of time.
13 Heuristic expiration
MUST be included if the cache heuristically chose a freshness
lifetime greater than 24 hours and the response's age is greater than
24 hours.
Fielding, et. al. Standards Track [Page 138]
RFC 2068 HTTP/1.1 January 1997
14 Transformation applied
MUST be added by an intermediate cache or proxy if it applies any
transformation changing the content-coding (as specified in the
Content-Encoding header) or media-type (as specified in the
Content-Type header) of the response, unless this Warning code
already appears in the response. MUST NOT be deleted from a response
even after revalidation.
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.