Joe Orton 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 filter does > nothing for a HEAD request? Because of the concern that a HEAD will > return a different C-L & C-E to a GET on the same resource with the same > Accept-Encoding header? Does 2616 mandate that a resource must always > exactly the same set of content-codings across methods and time? > (AFAICT there is no MUST on that front; it's a SHOULD if anything)
Read through to the end, it breaks all proxied content; 9.4 HEAD The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request. This method can be used for obtaining metainformation about the entity implied by the request without transferring the entity-body itself. This method is often used for testing hypertext links for validity, accessibility, and recent modification. The response to a HEAD request MAY be cacheable in the sense that the information contained in the response MAY be used to update a previously cached entity from that resource. If the new field values indicate that the cached entity differs from the current entity (as would be indicated by a change in Content-Length, Content-MD5, ETag or Last-Modified), then the cache MUST treat the cache entry as stale.
