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

tor 2006-09-07 klockan 15:12 -0700 skrev Mark Nottingham:

> I'm guessing that's the full URL.

Yes, of course it is.

> It would be nice if there were an
> option to ignore the query string for this purpose;
>
> E.g., if Squid sees
> http://example.com/search?q=foo
> and finds it's uncacheable, it would then stop collapsing other
> requests with the same base, e.g.,
> http://example.com/search?q=bar

A bit hard as it requires keeping a cache of uncacheable content, and to
make multiple cache lookups before knowing what to do with the request.

Normally query requests is set uncachable by default in squid.conf by
the cache directive, making the collapsed_forwarding directive a noop on
those requests as it only applies on requests which may be cached to
begin with.

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.

> 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..

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. Currently we don't speculate at all and
collapsed_forwarding always assumes responses will be cachable until
proven otherwise.

Regards
Henrik