ISSUE: Warning as a general header....

At 11:39 7/25/98 -0700, Jim Gettys wrote:
>I've done one scan trying to catch all the Warning usages that should
>change...

As we talked about, when the warning header is described directly in
connection with a cache then it should be "response" and not message as a
cache by definition only works on responses. That is, 1xx codes only make
sense for response, 2xx codes can be applied both to requests and responses.

I don't know if it is of any use to define directions on future codes - I
don't like the codes in the first place. Had they been URIs then I could
have used them in Mandatory and 118n problems would have been the same as
for any other resource. If anybody else would like to do that then feel free!

Section 13.1.2

Whenever a cache returns a response that is neither first-hand nor "fresh
enough" (in the sense of condition 2 in section 13.1.1), it must attach a
warning to that effect, using a Warning response-header. This warning
allows clients to take appropriate action

The "must" should be a MUST in the paragraph above. "response-header"
should be "general-header".

In the section a bit further down:

HTTP/1.0 caches will cache all Warnings, without deleting the ones in the
first category. Warnings that are passed to HTTP/1.0 caches carry an extra
warning-date field, which prevents a future HTTP/1.1 recipient from
believing an erroneously cached Warning.

Change "HTTP/1.0 caches will cache all Warnings" to "HTTP/1.0 caches will
cache all Warnings in responses".

Change "Warnings that are passed to HTTP/1.0 caches" to "Warnings in
responses that are passed to HTTP/1.0 caches"

Section 13.5.2

A non-transparent proxy MAY modify or add these fields in a response that
does not include no-transform, but if it does so, it MUST add a Warning 114
(Transformation applied) if one does not already appear in the response.

Change "in a response" to "in a message" and "if one does not already
appear in the response" to "if one does not already appear in the message"

Section 14.46

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.

Change "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" to "The Warning general-header field is used to
carry additional information about the status or transformation of a
message which may not be otherwise reflected in the message."

Change "This information is typically, though not exclusively, used to warn
about a possible lack of semantic transparency from caching operations." to
"This information is typically used to warn about a possible lack of
semantic transparency from caching operations or of transformations applied
to the entity body of the message."

Further down

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.

Change the whole paragraph to

Warning headers can in general be applied to any message, however some
specific warn-codes are specific to caches and can only be applied to
response messages. New Warning headers should be added after any existing
Warning headers. A cache MUST NOT delete any Warning header that it
received with a message. 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.

Next paragraph

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 character set take priority over
warnings in other character sets but with identical warn-codes and
warn-agents.

I am surprised that none of the GUI folks have complained about this
SHOULD. It isn't a protocol requirements and interferes with GUI policies.
If we want this paragraph then it SHOULD at least be a lowercase "should".

In the paragraph

1XX	Warnings that describe the freshness or revalidation status of the
response, and so MUST be deleted after a successful revalidation.

Add the sentence

1XX warn-codes MAY be generated by a cache only when validating a cached
entry. It MUST NOT be generated by clients.

Comments?

Henrik

--
Henrik Frystyk Nielsen,
World Wide Web Consortium
http://www.w3.org/People/Frystyk

Received on Tuesday, 28 July 1998 11:31:15 UTC