On 17 Oct 2010, at 2:29 PM, Ruediger Pluem wrote:
Are you sure? If the client said Cache-Control: no-cache, we IMHO
treat
the cached entry as stale and revalidate:
From cache_util.c:
/* This value comes from the client's initial request. */
cc_req = apr_table_get(r->headers_in, "Cache-Control");
pragma = apr_table_get(r->headers_in, "Pragma");
if (ap_cache_liststr(NULL, pragma, "no-cache", NULL)
|| ap_cache_liststr(NULL, cc_req, "no-cache", NULL)) {
if (!conf->ignorecachecontrol) {
/* Treat as stale, causing revalidation */
return 0;
}
ap_log_error(APLOG_MARK, APLOG_INFO, 0, r->server,
"Incoming request is asking for a uncached
version of "
"%s, but we have been configured to ignore it
and "
"serve a cached response anyway",
r->unparsed_uri);
}
If the client specified no-cache, the cache steps down completely, and
the client is guaranteed fresh content from the source server (as per
the RFC). The cache will only revalidate if you say max-age=X (or
other valid caching tokens).
What we do differently, is that instead of invalidating the existing
content with our 5xx response to the no-cache request, we leave it
alone completely, so that the next request, where the client hasn't
asked for no-cache, can be served the stale content, instead of an
error because the stale content had been blown away by the previous no-
cache request.
existing file at all, and cache->stale_handle would always be NULL.
Even then remains the question: Why doing it differently in both
case (ap_die, mod_proxy)?
We do it the same way in both cases, the remove_url filter is removed
in the ap_die() case on line 1630, and in the mod_proxy case inside
save_filter on line 791.
Remember that the save_filter isn't triggered at all in the ap_die()
case, so doing this inside save_filter isn't enough.
Regards,
Graham
--
