Joe Orton wrote: > 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.
Ok, rereading 9.4, it discusses "new field values indicate that the cached entity differs from the current entity" - new; not omitted. In the absence of the header, the entity doesn't "change". It is unknown. So a cache author can/should/would[?] treat it as fresh, as you point out with respect to 304. So +1 to the proposed patch; in fact, +1 on unsetting C-L and treating HEAD to the same processing as 304.
