On 26/09/2013 8:32 a.m., Manuel wrote:
Is it possible to do not refresh the cache in case of an error in the newest
request to the cache_peer?
If Squid has an error retrieving from a peer the broken response is
never cached. If you find evidence of an update happening that is a bug,
please verify if it still exists in the latest stable before reporting.
Please note however that receiving a 4xx or 5xx status code response
from the peer is a *successful* contact. The error is happening outside
of Squid and may be cached as per the caching rules for that response.
Squid is in no position to arbitrarily replace server notifications
about errors with stale content. (But keep reading...)
What I mean is; suppose that in a reverse proxy I want to refresh the cache
of the base URL (the homepage of the website) around every 60 seconds but in
case that the cache peers are temporarily unavailable I do not want to
refresh the cache because otherwise no content will be shown to the clients.
Is there are method to achieve this?
HTTP caching controls allow stale content to be served under certain
circumstances.
* if the client request *omitted* both max-age and no-cache options, and
* if the cached server response allows a heuristic estimate of
staleness, and
* if the server produced a 5xx status code implying the network or
server software was at fault rather than resource change.
That second clause about heuristics can take several forms (note these
have to be on the already cached response):
* the server may send an explicit stale-if-error=N cache control to
allow stale responses for up to N seconds
* the server sends stale-while-revalidate control (Squid-3 does not yet
support this)
In your case I would recommend having the server send stale-if-error=
control with some value for what you expect the longest reasonable
server outage to be. That will allow the stale content on errors.
For the 60 second revalidation:
* send ETag and Last-Modified if possible and make sure the server
properly handles the If-* conditional queries (If-Match,
If-Modified-Since, etc)
* send max-age=N with N set to a changing value of the current age of
the object (based on the Last-Modified) plus 60 seconds.
Avoid must-revalidate/proxy-revalidate cache control they will cause
either too-frequent revalidation. Expires header is HTTP/1.0 specific
and should be avoided, but if sent needs to be set dynamically to a
timestamp of now+60sec o each response to match the max-age trick.
Amos
