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 said I agreed with Roy on this, and I also agree with his
explanation on _why_ it is a bad thing.  I'm not sure I can explain my
objections any more clearly than Roy already did, but here is a try:

Your default value would force service authors to include a
Fresh-until: <some number> header in 99% of all HTTP/1.1 responses.
We have no guarantee that they will indeed do this.  In fact, the
recent statistic about the use of Expires headers suggests that many
will not.  If a significant faction does not, or is too late in doing
it, proxy maintainers will start ignoring the default of zero
specified in the protocol because they need to get at least the same
performance they got when caching HTTP/1.0 traffic.  Thus, we will end
up in a situation in which you can not longer trust proxies to conform
to the protocol they claim to conform to.  Very bad.  I can't
guarantee the above zero default collapse scenario _will_ happen, but
I see no justification for taking such a risk.

> in the next breath he agrees that there
>ought to be some finite value here.  I proposed "zero", he proposed
>"7 days",

I proposed the "7 days" as a maximum age before verification. Caches
would be free to check more often, and I expect them to do so on
resources without Fresh-until headers that were recently modified.

> and I think we can both agree that the other one's proposal
>is too extreme :-).  I'm happy to discuss the particular value, or
>recommended range of values, but I think it would be a mistake to leave
>it completely unconstrained.

I agree it would be a mistake (though not a huge mistake) to leave the
value unconstrained.  If the upper bound for a heuristically computed
lifetime is left unconstrained, service authors that decide to start
providing Fresh-until (max-age) headers with existing resources that
have already been around for some time could never be sure that their
new values ever overrule the heuristics of gigabyte caches.

You could never say `I fixed it: in 7 days, users behind the proxy of
gigacache.net won't see `happy xmas' on a single one of our 5000 pages
anymore'.  If service authors are not able to make such definite
claims (to management, for example) about improvements after the
introduction of Fresh-until (max-age) headers, they will be
discouraged from introducing these headers.

>-Jeff

Koen.

Received on Tuesday, 9 January 1996 17:18:43 UTC