On 10/15/2010 06:55 PM, Graham Leggett wrote:
> 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,
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?
> 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.
Ok, but why doing it differently in the ap_die case?
Regards
Rüdiger
