On 10/13/2010 12:54 AM, minf...@apache.org wrote: > Author: minfrin > Date: Tue Oct 12 22:54:06 2010 > New Revision: 1021946 > > URL: http://svn.apache.org/viewvc?rev=1021946&view=rev > Log: > mod_cache: Support stale-on-error behaviour for the mod_proxy case in > addition to the existing case where the error was generated by ourselves. > > Modified: > httpd/httpd/trunk/modules/cache/mod_cache.c > > Modified: httpd/httpd/trunk/modules/cache/mod_cache.c > URL: > http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/cache/mod_cache.c?rev=1021946&r1=1021945&r2=1021946&view=diff > ============================================================================== > --- httpd/httpd/trunk/modules/cache/mod_cache.c (original) > +++ httpd/httpd/trunk/modules/cache/mod_cache.c Tue Oct 12 22:54:06 2010 > @@ -779,6 +779,61 @@ static int cache_save_filter(ap_filter_t > > dconf = ap_get_module_config(r->per_dir_config, &cache_module); > > + /* RFC2616 13.8 Errors or Incomplete Response Cache Behavior: > + * If a cache receives a 5xx response while attempting to revalidate an > + * entry, it MAY either forward this response to the requesting client, > + * or act as if the server failed to respond. In the latter case, it MAY > + * return a previously received response unless the cached entry > + * includes the "must-revalidate" cache-control directive (see section > + * 14.9). > + * > + * This covers the case where an error was generated behind us, for > example > + * by a backend server via mod_proxy. > + */ > + if (dconf->stale_on_error && r->status >= HTTP_INTERNAL_SERVER_ERROR) { > + > + ap_remove_output_filter(cache->remove_url_filter);
Why doing ap_remove_output_filter that early? In the error filter case (when the error origins from ap_die()) this is done withing the "if (cache->stale_handle && ..." block. Is there any reason why we should not remove a cached entity when we have no stale_handle and the backend created an error code as response code? Regards Rüdiger
