Overview
Every LOCKSS cache runs a proxy server, and the intent is to always proxy users' requests through the cache (more on this below). When the cache receives a proxy request for content it doesn't have, it forwards it on to the actual site. If it does have the content, it still sends a GET to the publisher site, with an "if-modified-since" reflecting the cached content. If the publisher responds with newer content, it is served to the user. If the publisher DNS lookup fails, or it doesn't respond quickly, or it responds with an error or 304, LOCKSS serves the locally cached content. (And in the case of no response, it remembers for a little while that the host is down, so subsequent requests don't incur the timeout.)LOCKSS caches don't have the horsepower to proxy all requests for an institution; some means must be employed to route only the appropriate requests to it. The mechanism for this depends on the institution's existing cache/proxy architecture. LOCKSS can currently produce PAC files, to configure individual browsers, or a fragment of an EZproxy config file. LOCKSS also implements ICP, a communication mechanism used by proxy caches like Squid to ask each other whether they have a given piece of content and to respond to requests for content.
Specific Integration Stories
The above are all for production use, but if you simply want to audit the content in your LOCKSS box, see AuditCacheContent
