httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <rpl...@apache.org>
Subject Re: svn commit: r1021946 - /httpd/httpd/trunk/modules/cache/mod_cache.c
Date Sat, 16 Oct 2010 05:22:28 GMT


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



Mime
View raw message