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
