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
