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. 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. Regards, Joe
