httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <>
Subject Re: svn commit: r951222 - in /httpd/httpd/trunk: CHANGES modules/cache/mod_disk_cache.c
Date Sat, 05 Jun 2010 16:51:13 GMT

On 06/04/2010 05:09 PM, Graham Leggett wrote:
> On 04 Jun 2010, at 4:15 PM, Plüm, Rüdiger, VF-Group wrote:
>> IMHO it does not (at least according to the comments and the code
>> looks like
>> to follow these):
> This is only present on trunk, and this needs to be fixed too. The
> problem we saw was in httpd v2.2.

A similar code is part of 2.2. Hence I am still astonished why you
see this problem in 2.2.

>>> implementation (mod_disk_cache) to decide whether it wants to
>>> handle a
>>> 206 or not.
>>> mod_cache is not the place to fix this. It is entirely valid for a
>> So you think that should be fixed in every single provider?
> Yes.
> Each provider should have the opportunity to cache a 206 if it so
> wishes, as RFC2616 allows it. Remember that providers don't have to be
> written by us.
> Any provider that chooses not to support a 206 should explicitly do so,
> not rely on mod_cache to enforce a blanket ban on supporting 206
> response caching.
>> I am currently not convinced that any provider could cache a 206 with
>> the current mod_cache infrastructure.

I am currently worried that a fresh cached copy of a 206 response cannot
be updated accordingly if a full response is requested. That puts the burden
of this stuff on each provider instead of some general framework solution
in mod_cache. So I think mod_cache should provide a better framework for
206 responses first before providers should implement it.



View raw message