httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch ...@sfritsch.de>
Subject Re: svn commit: r1343951 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS modules/cache/mod_cache.c modules/cache/mod_disk_cache.c modules/cache/mod_mem_cache.c
Date Fri, 01 Jun 2012 13:36:23 GMT
On Friday 01 June 2012, Ruediger Pluem wrote:
> sf@apache.org wrote:
> > Author: sf
> > Date: Tue May 29 19:55:37 2012
> > New Revision: 1343951
> > 
> > URL: http://svn.apache.org/viewvc?rev=1343951&view=rev
> > Log:
> > Merge r933919, r951222:
> > 
> > * Do not cache 206 responses in any case since we currently do
> > not provide any
> > 
> >   backends that are capable to cache partial responses. PR 49113.
> >   Fixes regression of r724093.
> > 
> > Submitted by: minfrin
> > Reviewed by: rjung, wrowe, sf
> > 


> Sorry for chiming in that late
> I don't think that this is the correct combination of the
> backports. The r->status != HTTP_PARTIAL_CONTENT needs to move up
> one if condition such that the check allows to cache partial
> responses in any case and let the providers deny it (like in trunk
> and 2.4). The current patch never forwards a partial response to
> the providers and hence never triggers the code in the providers.

Yes, I have noticed that the proposed patch basically forbids caching 
206 responses, twice. I have still voted +1 because it is a 
significant improvement (inefficient caching versus corrupt response) 
and because it seems very unlikely that any of the 2.2 providers will 
get support for 206 (considering that 2.4 is out).

If anyone thinks this is (or may become) a problem, we can backport 
r952823, too.

Cheers,
Stefan

Mime
View raw message