> Hello, Leonardo. > > Thanks for your prompt reply! > > On 8/21/08 3:02 PM, "Leonardo Rodrigues Magalhães" > <leolistas@xxxxxxxxxxxxxx> wrote: >> are you sure you wanna do this kind of configuration ??? > Yes. I am aware that my request is unusual, as this is to be a > special-purpose installation of squid. > >> have you >> ever imagined that you can be feeding your users with really >> invalid/very outdated pages ??? > Of course -- it is implicit in my request. The "users" of this particular > squid instance will not be humans with desktop browsers, but other > software > systems that need a layer of "availability fault-tolerance" between > themselves and the URL resources they depend on. > >> If the site admin took the files off off >> the webserver, maybe there's some reason for that .... > The servers this Squid server will pull URLs from are many and diverse, > and > maintained by admins with widely different competency levels and uptime > expectations. > >> i dont know if this can be done, > Bummer. After all that explanation of why I shouldn't, I thought for sure > you were going to say "But if you REALLY want to...". ;) > > So, now that I have explained my need, the question reamins unanswered: > Is it possible to configure Squid so that it always serves the "latest > available" version of any given URL, even if the URL is no longer > available > at the original source? > Thats how HTTP works, yes. 'latest available', only what you don't seem to understand is that a 404 page IS the latest available copy when an object has been administratively withdrawn. Your fault-tolerance requirement, brings to mind the stale-if-error capability recently sponsored into Squid 2.7. That will let squid serve a stale copy of something if the origin source fails. I'm not too savy on the details, but its worth a look. It should get you past a lot of the possible temporary errors. To achieve 100% retrieval of objects is not possible. Any attempt at it ends up serving stale objects that should never have been stored. The closest you can get is to: a) use the stale-if-error where you can be sure its safe to do so b) get as many of the source apps/servers to provide correct caching control headers. c) admit that there will be occasional 404s coming out (but rarely in a well tuned system) Given the variance in levels of admin knowledge, you can confidantly say the Squid layer handles a certain level of faults and recovery, and provides a higher level than it accepts. Then you can start beating the admins both at supply and drain, with clue-stick when their apps fail to provide sufficient confidence on the Squid input or fail to handle a low level of faults. As the problem is entirely theirs and you can prove it by comparison with the working app feeds. The using software MUST be able to gracefully cope with occasional network idiocy. Anything less is a major design flaw. Amos
