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
>>> BNICHOLES@novell.com 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
|