On 10/16/2010 01:01 PM, Graham Leggett wrote:
> On 16 Oct 2010, at 7:22 AM, Ruediger Pluem wrote:
>
>>> It's because if we don't do this, the very first user who sends
>>> "Cache-Control: no-cache" will cause the entry to become invalidated,
>>
>> Hm. Invalidated? We might have no stale entry, so what I am asking
>> about is the
>> case of a fresh 5xx response with no previous stale entry. Why do we
>> remove
>> cache->remove_url_filter in this case?
>
> The url_filter's job is to invalidate and physically remove the existing
> entry. We add the url_filter very early on, and then when we're certain
> we have no need to remove the existing entry, we remove the filter.
>
> The cache->stale_handle value doesn't tell us whether a stale entry is
> present or not. Instead, it tells us that when we tried to open the
> existing entry, and we looked at the headers in the entry, and the
> headers provided by the client, we eventually concluded that in this
> specific case, we should consider the content stale. If the client said
> "Cache-Control: no-cache", we wouldn't have even tried to open the
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);
}
> 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)?
Regards
Rüdiger
