httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <>
Subject Re: svn commit: r1021946 - /httpd/httpd/trunk/modules/cache/mod_cache.c
Date Sun, 17 Oct 2010 12:29:32 GMT

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",

> 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)?



View raw message