On 14 Oct 2010, at 8:58 PM, Ruediger Pluem wrote:
+ /* 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?
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, and we
go from having a stale entry, to having no entry at all, and everyone
gets a 5xx from that point on.
This isn't to say that we ignore the no-cache, the user that requested
no-cache will get no-cache behaviour and the 5xx response, but this no-
cache doesn't blow away the stale data for other people.
If we want to add an additional directive to offer control over this
it's fine, but I'm hoping that this is reasonable behaviour given that
the admin has asked for stale-on-error behaviour for 5xx responses.
Regards,
Graham
--
