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: r951222 - in /httpd/httpd/trunk: CHANGES modules/cache/mod_disk_cache.c
Date Mon, 07 Jun 2010 06:19:17 GMT


On 06/06/2010 01:35 PM, Graham Leggett wrote:
> On 05 Jun 2010, at 6:51 PM, Ruediger Pluem 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.
> 
> I think we're talking across purposes, the code in the most recent v2.2
> branch I am looking at looks like this with the comments stripped:

Ah, sorry I missed the inner if which was added in r727599. You are correct,
2.2 caches 206 with expire or cache-control set.

> 
>> 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.
> 
> I don't follow what mod_cache would need to do in this case with respect
> to a 206 that makes a cache implementation require special support.
> 
> If a cache implementation wanted to, it could cache the 206, marking the
> range in the cache as appropriate. When a full request came along, the
> cache could potentially modify the request to ask for the missing range,
> and then decline the opportunity to serve from cache. The backend
> supplies the missing range, and the cache_save filter saves the missing
> range to complete the request, and inserts the existing cached data into
> the response as a simple file bucket, completing the response.

I still fail to see how to integrate this easily with the current mod_cache
API, since you sure want to use all the generic freshness checks within
mod_cache. And if a copy is seen as fresh it is simply served.
But I guess this now goes OT and it would be better to discuss this in a
separate thread as soon as someone offers an implementation to actually
cache 206's. It is easier to discuss the exact code then.
Does someone actually plan to do this?

> If we did find a way to support a generic 206 mechanism in mod_cache,
> that would be great (assuming it was necessary), but the opposite,
> banning any caching implementation from even attempting to cache a 206
> by enforcing a ban in mod_cache itself isn't ideal, if that makes sense?

Ok, I am fine with that now. I guess the discussion might continue as soon
as we see the first implementation for caching 206's.

Regards

RĂ¼diger

Mime
View raw message