Re: What can you cache? [was: Byte ranges -- formal spec proposal ]

On Thu, 18 May 1995, Daniel W. Connolly wrote:

> 
> Why can't byte ranges be cached? What's the difference between caching
> requests with ;byterange= in the URI and those without? Why not cache
> CGI-bin responses? Granted, it's a pain to save their output (though
> if you do it in parallel with returning the data to the first
> requestor, everybody wins) and it's a pain to figure out the age of
> all the data sources that go into a CGI computation. But in theory,
> there's no reason they can't be cached.

UNTIL we have reliable protocols and defaults in HTTP implementations,
there is no way that cgi-bin output should be cached by default.
A get with query string or a post with exactly the same input
can have a different result. When the CGI program is interfacing
a data base it is quite likely to have a different result.

And we need an architected requirement that the end user CAN ALWAYS
request a "from the source" refresh.  In the http-ng timeframe I
hope we will be strongly considering protocols which allow much
more distributed data base like options for cache management. The
document owner should be able to track caching and notify cachers
of unexpected changes or even provide the refresh automatically.


> 
> Hmmm... perhaps a relative number of seconds isn't such a good
> idea... with cascading proxies, the time of the request could get
> skewed. The header should give the aboslute time of the most
> out-of-date copy that's acceptable:
> 
> 	Any-Copy-Since:	19950518153710Z

Surely, skew in relative seconds is preferable to guaranteed skew
in interprestation of an absolute time based on local system
clock.

Practically, system clocks can be skewed by minutes or more. Relative
time skew is more likely to vary by seconds.  At least if the
proxy adjusts the cache time remaining when providing a relative
cache expires limit to a requestor (UA or cascaded proxy same
issue)

Dave Morris

Received on Friday, 19 May 1995 13:39:43 UTC