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
