On 27/10/2015 5:14 p.m., Jester Purtteman wrote: > So, here's my theory: Setup <expensive-server> so that it caches > EVERYTHING, all of it, and catalogs it with this Digest. It doesn't expire > anything, ever, the only way something gets released from that cache is when > the drive starts running out of room. It's digest is then sent to > <cheap-server>, which doesn't cache ANYTHING, NOTHING. When a request comes > through from a client, <Expensive-Server> checks the refresh rules, and if > it isn't too stale it gets served just like it does now, but if it IS > expired, it then asks <Cheap-Server> "hey, how expired is this?" and > <Cheap-Server> (which has all the bandwidth it could ever want) grabs the > content, and digests it. If the digest for the new retrieval matches > something in the digest sent by <expensive-server>, then <cheap-server> > sends up a message that says "it's still fresh, the content was written by > lazy people or idiots, carry on". You just described what HTTP/1.1 revalidation requests do. In your logs as REFRESH_*. Though they have to send HTTP headers around to get it to work, which is a little more expensive than the Digest would be, the result is far more reliable and accurate. The Cache Digest is just a one-way hash of the URL entries in the cache index. It is for reducing ICP queries to a peer proxy (ie the frontend cheap server). If you dont have a cache at both end of the conection it is not useful. And like ICP it is full of false matches when used with modern HTTP/1.1. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
