> -----Original Message----- > From: Joe Orton [mailto:jor...@redhat.com] > Sent: Mittwoch, 15. Juli 2009 15:29 > To: dev@httpd.apache.org > Subject: Re: mod_deflate DoS using HEAD > > On Wed, Jul 15, 2009 at 11:03:24AM +0200, "Plüm, Rüdiger, > VF-Group" wrote: > > > I'm confused. Why do this check so late, and why does > r->bytes_sent > > > matter? Why does it "screw up the protocol" if the DEFLATE > > > > All depends on the first brigade that passes mod_deflate. > If this brigade > > contains the whole response *and* mod_deflate can compress > this response > > in one go meaning calling ap_passbrigade only once to sent > the fully compressed > > response then the content-length filter can determine the > length of the content > > and add it to the HEAD response as the same GET request > would be delivered > > with a C-L. > > I understand that, but, the whole point of doing the check early, as > Eric's proposed patch did, is to *avoid* doing all that work > because it > may be exhorbitantly expensive, even in the case of a single brigade > containing the whole response - that's the issue in hand.
It isn't really this expensive, because of the second condition. Each time the internal zlib outgoing buffer with the compressed data within is full we pass this data down the chain. We don't buffer this data in the filter. It is a good filter :-). This means if this passing is not the *only* passing mod_deflate does down the chain we cannot go the C-L road anyway. So most larger responses even in one brigade if not extremely compressable will cause mod_deflate aborting compression in this case. IMHO the rule is that if the C-L of the compressed response is larger than the size of zlibs outgoing buffer we will sent the response in T-E chunked anyway. Thus we can stop compressing for a HEAD request once we got over this limit which should happen fairly early. > > The GET/304 case already omits the C-L from the response, so, > I'm still > struggling to see how doing the same for HEAD somehow breaks HTTP > caching in any way. IMHO it can cause an unnecessary invalidation of a cache entry. This is not nice. Whether this could be called a "break" is another story. Regards Rüdiger
