Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: <4C0A8081.2080009@apache.org>
Date: Sat, 05 Jun 2010 18:51:13 +0200
From: Ruediger Pluem <rpluem@apache.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.8.1.24) Gecko/20100301 SeaMonkey/1.1.19
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: svn commit: r951222 - in /httpd/httpd/trunk: CHANGES
 modules/cache/mod_disk_cache.c
References: <20100604001717.3A9762388999@eris.apache.org>
 <4C088EBB.1090509@apache.org> <7BC3EF30-FF15-457C-8A70-94E54219281A@sharp.fm>
 <99EA83DCDE961346AFA9B5EC33FEC08B0407DE07@VF-MBX11.internal.vodafone.com>
 <ECACF9E5-51E8-4231-B7DD-8F115CAF570E@sharp.fm>
In-Reply-To: <ECACF9E5-51E8-4231-B7DD-8F115CAF570E@sharp.fm>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit


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.

Regards

R�diger