Re: Cache behavior in the absence of a Fresh-until: header

    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.
    
I think I generally agree with you, although I'm not sure why
you are suggesting this so perhaps we are using the same terms
to mean different things.

I'd prefer to use slightly different words, to be more precise:
The protocol design should use *declarative* rather than *procedural*
techniques whenever possible, since that tends to give the
implementations more flexibility.

But even if we agree here, what this actually means is a matter
of interpretation.  For example, I view the Fresh-until: value
as purely declarative, saying that "you can safely assume that
this response I am giving you is not going to change significantly
for that many seconds".

On the other hand, something like "Cache-control: reload" is
apparently procedural, but I suspect that we cannot do without
a few such features.

    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,

Can you give a scenario where this is different from "Fresh-until:
forever"?  And would you be satisfied if (as I proposed the other
day) the protocol included an explicit way to say "I have no
information to give you about the fresh-until time of this resource"?
    
    but also because this is what HTTP/1.0 servers
    currently do. Interoperability with HTTP/1.0 should be a high
    priority.

I most certainly addressed this issue in my proposal, requiring
caches to use a heuristic to choose a fresh-until value for
responses that come from HTTP/1.0 servers.  I left the heuristic
undefined for now, because I'm not sure what HTTP/1.0 caches
actually do.  In fact, the combined effect of my proposal is
to tend towards lenience, since I suspect that if an HTTP/1.1
server sends a response without Fresh-until:, which is proxied
through an HTTP/1.0 cache, and then received by an HTTP/1.1 cache,
the latter would believe that it has received a value from an
HTTP/1.0 origin server and should NOT assume a value of zero.

    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.

Is this what HTTP/1.0 caches do: keep things for 7 days?  Or does
the practice vary?  Any experts out there?

-Jeff

Received on Wednesday, 10 January 1996 03:03:23 UTC