httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: svn commit: r1021946 - /httpd/httpd/trunk/modules/cache/mod_cache.c
Date Sun, 17 Oct 2010 15:57:02 GMT
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
--


Mime
View raw message