Re: [squid-users] any thought to making collapsed_forwarding acl-based?

Neil Harkins wrote:
> hi. this might belong on squid-dev, but figure i'll try here first.
>
> squid doesn't know if an object is even cacheable until it gets
> the headers back from origin, thus collapsed forwarding seems
> to impair performance of non-cacheable content, by blocking
> what will have to be a separate request anyway.
>
> most site administrators know what's cacheable or not on their site,
> and could craft regex to differentiate thus collapsed_forwarding
> being acl-based would be extremely beneficial, but it appears
> to be global on/off today. is this conclusion correct? are there
> any architectural reasons why it would be a bad idea?

Well, most administrator set Cache_Control page headers much more easily
than embedding regex patterns in URL. Which work on every cache
worldwide instead of just the local reverse-proxy (if any).

Collapsed-forwarding is external to the cache. Just because the local
admin has not chosen (legal or policy Reasons) to store large .divx
files in local cache, does not mean there is no benefit from
collapsed-forwarding on those items.

>
> another way to optimize it would be to restrict it to revalidations only,
> not misses. then it would only apply to what is known to have been cachable.

There is a large subset of multicast-objects which are
non-cacheable-objects. The above is one example, true multicast
streaming audio/video is another. Torrents and Onions, yet another,
While Squid does not support those yet they are currently under discussion.

Amos

-- 
Please use Squid 2.6STABLE17+ or 3.0STABLE1+
There are serious security advisories out on all earlier releases.