httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: svn commit: r951222 - in /httpd/httpd/trunk: CHANGES modules/cache/mod_disk_cache.c
Date Fri, 04 Jun 2010 15:09:53 GMT
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.

>> 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.

There was nothing in the original design for mod_cache that stopped a  
provider trying to cache a 206.

>> cache implementation to be given the opportunity to cache a 206, if
>
> Right, RFC2616 permits caching 206's.

Regards,
Graham
--


Mime
View raw message