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

Jeffrey Mogul writes:
	...
 > I'm also open to discussion of the value that caches should
 > assume, but I think it is important to understand *why* I
 > think the value should be zero before dismissing it.  For
 > one thing, if caches assume a value of zero, there is a strong
 > incentive for HTTP server implementations to comply with my
 > proposed requirement that they always send a value of some sort.
 > 

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.

 > Also, I'm trying to err on the side of safety rather than performance.
 > Any heuristic value other than zero leaves open the possibility of a
 > mistake (leading to the user seeing the wrong thing).
 > 
Whenever it is important that people not see previous versions 
of documents, isn't is reasonable to put the onus of that onto the
server operators?


 > Remember, my goal is NOT to force any particular behavior, but
 > to ensure (as much as possible) that all parties are explicit
 > about what they want, so that caches do not need to make inferences.

Sometimes, somebody somewhere has to make inferences.  Server
operators are usually in the best position to know this information,
but is it really better for them to put in fabricated information than
it is for a cache to fabricate information?


 > Elsewhere you have argued eloquently that the server should be
 > in firm control of the situation, because the "application" semantics
 > are only fully known to the server.  I agree with you on this point,
 > and I think it would be a real mistake to rely on a purely
 > heuristic approach to get the caches to follow the servers' wishes.
 > 
There are cases where it really matters a lot, and cases where it
hardly matters at all.  The latter are the vast majority.  The former
need adequate support, which the protocol will provide.  These
questions are about the "vast majority" case.

 > Aside from this confusion (which I'll take full blame for), Koen and
 > I clearly agree that some maximum freshness lifetime needs to be
 > imposed in the absence of a server-supplied value.
 > 
 > -Jeff

Hmm. I don't.  Here's how I see this going down: if a header is
required, people who write servers will make sure there is one with
some default value as set up by default configuration parameters.  It
is every bit as likely that server operators will fail to configure
their server's freshness headers properly (or at all) if the server
inserts a standard default value as it would be if the server omitted
the header altogether in the absence of explicit directives (if that
were legal in the protocol).  If a header was required, I suppose
servers could beep and flash messages on the screen if no header
value was set up, and that would force someone to think about it.  Is
that the desired effect?  My guess is that where it matters, people
will already be motivated to think about it.

An argument in favor of omitting the header altogether instead of
putting in inadequately considered default values is that no
downstream cache would be inclined to take the value seriously if it
weren't there (under essentially false pretenses) to begin with.  Then
caches could potentially do a better job.  Suppose two server vendors
choose wildly different default values, and a cache is holding a lot
of pages from both kinds.  With such misleading explicit information,
the cache may make a lot of bad decisions that it could avoid in the
absence of the misinformation.


--Shel

Received on Wednesday, 10 January 1996 04:38:43 UTC