- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 05 Aug 2009 21:31:41 +0200
- To: Mark Nottingham <mnot@mnot.net>
- CC: Henrik Nordstrom <henrik@henriknordstrom.net>, HTTP Working Group <ietf-http-wg@w3.org>
Mark Nottingham wrote:
> +1. Talking about languages when the charset is constrained -- as well
> as when it's not intended for end-user interpretation -- makes no sense.
>
> I'd be more reticent to take this path, BTW, if there were any
> implementation of Warning in UAs. However, since as far as we know there
> isn't, it seems reasonable.
> ...
Ack.
I have removed more text, proposed patch:
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/187/187.2.diff>.
That would make the whole section read:
--
3.6. Warning
The general-header field "Warning" is used to carry additional
information about the status or transformation of a message that
might not be reflected in the message. This information is typically
used to warn about possible incorrectness introduced by caching
operations or transformations applied to the entity body of the
message.
Warnings can be used for other purposes, both cache-related and
otherwise. The use of a warning, rather than an error status code,
distinguish these responses from true failures.
Warning headers can in general be applied to any message, however
some warn-codes are specific to caches and can only be applied to
response messages.
Warning = "Warning" ":" OWS Warning-v
Warning-v = 1#warning-value
warning-value = warn-code SP warn-agent SP warn-text
[SP warn-date]
warn-code = 3DIGIT
warn-agent = ( uri-host [ ":" port ] ) / pseudonym
; the name or pseudonym of the server adding
; the Warning header, for use in debugging
warn-text = quoted-string
warn-date = DQUOTE HTTP-date DQUOTE
Multiple warnings can be attached to a response (either by the origin
server or by a cache), including multiple warnings with the same code
number, only differing in warn-text.
When this occurs, the user agent SHOULD inform the user of as many of
them as possible, in the order that they appear in the response.
Systems that generate multiple Warning headers SHOULD order them with
this user agent behavior in mind. New Warning headers SHOULD be
added after any existing Warning headers.
Warnings are assigned three digit warn-codes. The first digit
indicates whether the Warning is required to be deleted from a stored
response after validation:
o 1xx Warnings that describe the freshness or validation status of
the response, and so MUST be deleted by caches after validation.
They MUST NOT be generated by a cache except when validating a
cached entry, and MUST NOT be generated by clients.
o 2xx Warnings that describe some aspect of the entity body or
entity headers that is not rectified by a validation (for example,
a lossy compression of the entity bodies) and MUST NOT be deleted
by caches after validation, unless a full response is returned, in
which case they MUST be.
If an implementation sends a message with one or more Warning headers
to a receiver whose version is HTTP/1.0 or lower, then the sender
MUST include in each warning-value a warn-date that matches the Date
header in the message.
If an implementation receives a message with a warning-value that
includes a warn-date, and that warn-date is different from the Date
value in the response, then that warning-value MUST be deleted from
the message before storing, forwarding, or using it. (preventing the
consequences of naive caching of Warning header fields.) If all of
the warning-values are deleted for this reason, the Warning header
MUST be deleted as well.
The following warn-codes are defined by this specification, each with
a recommended warn-text in English, and a description of its meaning.
110 Response is stale
SHOULD be included whenever the returned response is stale.
111 Revalidation failed
SHOULD be included if a cache returns a stale response because an
attempt to validate the response failed, due to an inability to
reach the server.
112 Disconnected operation
SHOULD be included if the cache is intentionally disconnected from
the rest of the network for a period of time.
113 Heuristic expiration
SHOULD be included if the cache heuristically chose a freshness
lifetime greater than 24 hours and the response's age is greater
than 24 hours.
199 Miscellaneous warning
The warning text can include arbitrary information to be presented
to a human user, or logged. A system receiving this warning MUST
NOT take any automated action, besides presenting the warning to
the user.
214 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, or the entity-body of the
response, unless this Warning code already appears in the
response.
299 Miscellaneous persistent warning
The warning text can include arbitrary information to be presented
to a human user, or logged. A system receiving this warning MUST
NOT take any automated action.
--
BR, Julian
Received on Wednesday, 5 August 2009 19:32:25 UTC