W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1996

Re: 13.1.2 Warnings

From: Roy T. Fielding <fielding@liege.ICS.UCI.EDU>
Date: Fri, 18 Oct 1996 16:49:48 -0700
To: Ari Luotonen <luotonen@netscape.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <9610181649.aa19562@paris.ics.uci.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1818
>> Ummm, is there some reason why an HTTP/1.1 user agent cannot tell
>> for itself whether or not a message is stale?  After all, the
>> same information that made the proxy decide to add the Warning
>> header is still present in the cached message, and that information
>> can be interpreted by the HTTP/1.1 user agent just as easily as the
>> HTTP/1.1 proxy.
> Only the proxy knows its own configuration, which contributes to the
> decision of whether or not the proxy does an up-to-date check or not.
> The Warning header is the only means of telling the client of that
> fact.

That the validation failed, yes, but whether or not a message is stale
is a property of the message, not of the proxy.  The fact that no validation
was performed is visible in the Date and Age, so there is no need to warn
the user agent about that. It just strikes me as a bit weird to add the
warning, and I can't remember why it was needed in the first place.

>> BTW, that begs the question of why the client is being warned about
>> something that should be obvious from the Date, Age, and Expires/max-age?
> See above.  The proxy has config parameters only known to itself,
> which affect the cache control policy.

But the cache control policy has no impact on whether the message is
stale or not -- freshness is a simple calculation based on the data included
with the message and the time the proxy requested it, and all of that data
is required to be passed on to the client when the response is retrieved
from a cache.

>> As a separate issue, Warning is one of the headers that should be
>> listed as MUST be sent in a 304 response, with the lack of such a header
>> meaning remove any existing Warning messages from the cached entity.
>> That would settle the problem entirely, I think.
> Not, because HTTP/1.0 doesn't do any of that header wiggling stuff in
> the cache.

Any valid HTTP/1.0 cache must do the header wiggling stuff -- that has been
part of the 304 definition since we defined it on www-talk 2.5 years ago.
Of course, this only matters with proxy and server-based caches, many of
which ignore the basic requirements of caching.  Holding on to stale
warnings is the least of their worries.

Received on Friday, 18 October 1996 16:55:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:16:21 UTC