This patch also looks bogus given the fact that the content-length header for a r->header_only request is already being handled in ap_http_header_filter(). Removing all Content-Length: 0 headers in the ap_content_length_filter() seems like overkill.
Brad >>> [EMAIL PROTECTED] Tuesday, December 07, 2004 10:14:28 AM >>> It appears that the patch for bug 18757 which disallows a content-length header for all requests with a content-length of 0 is too broad. Index: D:/Projects/2.x/httpd-trunk/server/protocol.c =================================================================== --- D:/Projects/2.x/httpd-trunk/server/protocol.c (revision 104639) +++ D:/Projects/2.x/httpd-trunk/server/protocol.c (revision 104923) @@ -1244,8 +1244,11 @@ * * We can only set a C-L in the response header if we haven't already * sent any buckets on to the next output filter for this request. + * + * Also check against cases of zero bytes sent, to avoid a bogus + * C-L on HEAD requests, or no-body GETs like 204s. */ - if (ctx->data_sent == 0 && eos) { + if (ctx->data_sent == 0 && eos && r->bytes_sent > 0 ) { ap_set_content_length(r, r->bytes_sent); } Property changes on: D:/Projects/2.x/httpd-trunk/server/protocol.c ___________________________________________________________________ Name: cvs2svn:cvs-rev - 1.150 + 1.151 The bug simply says that the content-length should be removed just for HEAD requests. By removing it for all requests including an OPTIONS requests, causes the SSL handshake to fail after a TLS upgrade (somebody with more knowledge of SSL would have to explain why). According to the bugzilla report, this patch didn't completely resolve the issue anyway. I will be reverting the patch shortly unless somebody has a better fix. Brad