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

Shel writes:
    The issue seems to boil down to whether servers have to include a
    Fresh-until header even if their operators have no better idea of the
    lifetime of the documents than a cache could.  In this case I don't
    see that it matters much who fabricates the information.  Since there
    presumably should be some means of representing the fact that a server
    has no idea about the lifetime of a document, one obvious encoding of
    that would be to leave out the Fresh-until header.  Another encoding
    would be to put in a special token as a value that indicates the lack
    of information.  These are completely equivalent.

And Larry writes:
    For the first problem, the proposal just moves the blame around.
    You can either blame the author, the server author, the server
    administrator, the cache, or the user, and now, you'll be able to
    blame the server administrator.

Exactly!    

Let me explain.  We apparently have the problem that it may be
the case that an implementation has to fabricate a freshness
lifetime, because the person who "should" have done that didn't.
We have a choice between "expect the origin server to fabricate
it" and "expect the cache to fabricate it".

Shel says it doesn't matter ("much"), but I think this is a
mistake.  Consider what happens when something goes wrong.

If the server administrator (or service author) sets the wrong
default value for the freshness lifetime, the consequences are:
	relatively immediate
	directly linked to the server
	relatively easy to debug
That is, the person who set the wrong value will probably find
out soon enough, either because the server load gets quite high,
or because the users start complaining about inconsistent results,
depending on which way the value was "wrong".
	
If a cache administrator sets the wrong the default, on the
other hand, the consequences are:
	transient and perhaps delayed
	spread out among lots of servers
	hard to trace to a specific cache
	hard to debug
Most users who get inconsistent (stale) results won't know
whom to complain to (especially if there are multiple proxies
involved, or if their proxies are auto-configured).  The users
will probably complain to the service owner (if to anyone)
since that's the only "obvious" place to complain, but the
service owner may not be able to tell easily which proxy
is misconfigured, and may not be able to find a way to
convince the proxy owner to fix things.  And the consequences
of the proxy's misconfiguration may take a long time to
become obvious, making it that much harder to debug.

So, as Larry observes, I am trying to shift the blame to
the (origin) service administrator, because that's the
best place for it to be.

Roy recently wrote:
    [People] who benefit from a feature should be the ones doing the
    work necessary to enable it, while at the same time people who do
    not benefit from a feature (or simply do not *perceive* a benefit)
    should not be required to perform extra work in order to enable
    that feature for others.
I think this is exactly the right principle to apply here.  Cache
owners don't get much benefit from configuring the right default
(or more precisely, they don't get much burden from configuring
the wrong one).  If a cache is misconfigured, the inconsistent
results or extra server load will be spread out among lots of
servers, and the users will almost certainly complain to the
origin-server people before they complain to the cache-people.

Meanwhile, as several people observed, the precise details
of the service semantics are known only at the server site,
and so if there is any benefit to be gained from flexibility
in configuration, it's mostly gained by the server owner.

So I would suggest that it is a bad idea to give cache adminstrators
too much freedom to choose configuration parameters that affect
the ability of the server to control what the user sees.  We should
move the flexibility, as much as possible, to the server side of
things, because that's where the blame will naturally go.

-Jeff

Received on Thursday, 11 January 1996 01:08:39 UTC