Re: [squid-users] delivering stale content while fetching fresh

On 2006/09/07, at 4:33 PM, Henrik Nordstrom wrote:

> In accelerator setups which this is primarily targeted for I don't
> think
> it's that hard to add some rules telling which query URLs are cachable
> and which are not if you want to collapse requests for some query
> URLs.

Fair enough, good point.

>> Even better, a response cache-control extension could control this...
>
> Personally I think that only complicates matters. If doing this
> speculation abour URL relationships then I suspect results is
> sufficiently good deducing it automatically. Adding a new response
> directive to hint about this is only relevant in cases where the same
> base URL sometimes is cachable sometimes not, and having it
> automatically toggle based on what was last seen is probably
> optimal as
> it may be a bit hard for the server to guess what the next request
> pattern will look like..

My goal was more to move configuration off the box and into the hands
of the server, which is useful for shared accelerators. Of course,
there are other ways to achieve that; having response headers for one
object affect another's handling is useful, but does add a lot of
complexity.

> Note: Same reasoning can be made about file extensions, directories
> etc.
> Question is how far to go into this guessing of likelyhood that the
> response will be cachable.

Agreed. I was thinking more about a general mechanism using a
template; <http://www.ietf.org/internet-drafts/draft-nottingham-http-
link-header-00.txt>

Cheers,

--
Mark Nottingham
mnot@yahoo-inc.com