Do not send a content-length if and only if this is a HEAD request and

the content-length is 0.  The problem is that the C-L on a HEAD response
has to be the correct C-L, but if a handler returns saying the handled
the request without sending data, the core sends an EOS down the filter
stack, and we compute a 0 C-L.

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86976 13f79535-47bb-0310-9956-ffa450edef68

diff --git a/modules/http/http_protocol.c b/modules/http/http_protocol.c
index 82e97709f442fcd7d12764888761311eb31f3adc..9b359b6e3a224c8b6ebdb2abe443898060918b23 100644 (file)
--- a/modules/http/http_protocol.c
+++ b/modules/http/http_protocol.c
@@ -2503,6 +2503,23 @@ AP_CORE_DECLARE_NONSTD(apr_status_t) ap_http_header_filter(ap_filter_t *f, ap_bu
         apr_table_addn(r->headers_out, "Expires", date);
     }
 
+    /* This is a hack, but I can't find anyway around it.  The idea is that
+     * we don't want to send out 0 Content-Lengths if it is a head request.
+     * This happens when modules try to outsmart the server, and return
+     * if they see a HEAD request.  Apache 1.3 handlers were supposed to
+     * just return in that situation, and the core handled the HEAD.  In
+     * 2.0, if a handler returns, then the core sends an EOS bucket down
+     * the filter stack, and the content-length filter computes a C-L of
+     * zero and that gets put in the headers, and we end up sending a 
+     * zero C-L to the client.  We can't just remove the C-L filter,
+     * because well behaved 2.0 handlers will send their data down the stack, 
+     * and we will compute a real C-L for the head request. RBB
+     */
+    if (r->header_only && 
+        !strcmp(apr_table_get(r->headers_out, "Content-Length"), "0")) {
+        apr_table_unset(r->headers_out, "Content-Length");
+    }
+
     apr_table_do((int (*) (void *, const char *, const char *)) compute_header_len,
                  (void *) &len, r->headers_out, NULL);