Re: HTTP Caching Design

>Jeffrey Mogul:
>>While Koen Holtman asserts that this:
>>  An HTTP/1.1 server SHOULD provide a fresh-until time with every
>>  cachable entity, but if it does not, the cache must assume a value of
>>  zero.
>>
>>"is a very bad thing" (why?),

I think this is very bad too; here is some more rationale.
Suggestion; that there should be general bias towards servers providing
descriptive rather than proscriptive information, i.e. headers should
carry information about the resource rather than commands on what the
client should do with the resource. Example: I originally suggested the
Vary: header be re-introduced as it supplies information to the client;
compare this with the URI header which supplies instructions for the client.

Anyway, my particular point is that any statement that 'the cache must
assume a [default] value of...' is very bad. The cache may well have other
information about the resource; this statement forbids the cache to make
use of this information. [Example; knowledge based on the particular server
software.]

By equating a lack of a Fresh-Until header with Fresh-Until: 0 or
Fresh-Until: 7days you remove the option of the server indicating 'I have
no information to give you about the fresh-until time of this resource'.
This is bad both because of the usefullness of this option, but also because
this is what HTTP/1.0 servers currently do. Interoperability with HTTP/1.0
should be a high priority.

By all means state 'in the absence of a fresh-until time, the cache may
assume a default of 7days'  -- the period of time should be chosen to
be in accord with the defaults in use by that currently existing caches.

David Robinson.

Received on Tuesday, 9 January 1996 18:22:34 UTC