Bug 18757 - Content-Length is removed from replies to HEAD requests
Summary: Content-Length is removed from replies to HEAD requests
Status: RESOLVED FIXED
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: Core (show other bugs)
Version: 2.0.45
Hardware: All All
: P3 critical with 21 votes (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: PatchAvailable
: 8677 21348 28571 35105 39837 (view as bug list)
Depends on:
Blocks: 8677
  Show dependency tree
 
Reported: 2003-04-07 11:41 UTC by Sami Tikka
Modified: 2011-09-17 19:53 UTC (History)
7 users (show)



Attachments
Patch file (unified diff) to fix #18757 (648 bytes, patch)
2003-11-26 13:52 UTC, Sami Tikka
Details | Diff
log file excerpts and 'testcase' (2.49 KB, text/plain)
2004-09-29 14:34 UTC, Ralf Stubner
Details
patch #3 (815 bytes, patch)
2005-10-19 00:00 UTC, Greg Ames
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Sami Tikka 2003-04-07 11:41:23 UTC
When a HEAD request is issued to Apache 2.0.45 (or earlier) configured as a
proxy, the reply is missing the Content-Length header. The problem is not really
in the proxy but in the CONTENT_LENGTH filter, which sets the Content-Length to
zero (because the HEAD reply has no body). Then later in the HEADER filter a
Content-Length header is removed if the length is zero. I believe the
CONTENT_LENGTH filter should not touch the existing Content-Length header if the
request is a HEAD request.

This is a critical problem because it makes Windows boxes unable to install
updates and fixes from the Internet via Apache proxy.

Index: protocol.c
===================================================================
RCS file: /home/cvspublic/httpd-2.0/server/protocol.c,v
retrieving revision 1.121.2.2
diff -u -r1.121.2.2 protocol.c
--- protocol.c	3 Feb 2003 17:32:00 -0000	1.121.2.2
+++ protocol.c	24 Mar 2003 10:10:49 -0000
@@ -1290,7 +1290,7 @@
      * 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.
      */
-    if (ctx->data_sent == 0 && eos) {
+    if (ctx->data_sent == 0 && eos && !r->header_only) {
         ap_set_content_length(r, r->bytes_sent);
     }
Comment 1 Jeff Trawick 2003-11-21 17:29:42 UTC
I'm going through the bug db to make sure patches are findable.  Please see 
http://httpd.apache.org/dev/patches.html
Comment 2 Sami Tikka 2003-11-26 13:52:11 UTC
Created attachment 9298 [details]
Patch file (unified diff) to fix #18757
Comment 3 Sami Tikka 2003-11-26 14:03:20 UTC
*** Bug 8677 has been marked as a duplicate of this bug. ***
Comment 4 Joshua Slive 2004-05-21 18:00:07 UTC
*** Bug 21348 has been marked as a duplicate of this bug. ***
Comment 5 Nick Kew 2004-09-01 12:26:56 UTC
Hmmm, votes 13, by five people!

The patch is not necessarily correct: we should set the same content-length on a
HEAD request as on the corresponding GET.  So it's only a bug when the HEAD is
already devoid of data at this point in the filter chain.

I'm committing a slightly different fix in CVS.  I'll add it here too.
Comment 6 Ralf Stubner 2004-09-29 14:34:16 UTC
Created attachment 12893 [details]
log file excerpts and 'testcase'
Comment 7 Anthony Albert 2004-11-05 21:44:05 UTC
Ran into this very problem.  Patch code resolved half of the issue of getting
Windows Update to work through Apache2 Proxy server.

Other half of the problem was checking to be sure that Apache was listening on
port 443 (SSL) and had the mod_proxy_connect loading.  Relevant sections of
httpd.conf:

Listen 80
Listen 443

LoadModule proxy_module        modules/mod_proxy.so
LoadModule proxy_http_module        modules/mod_proxy_http.so
LoadModule proxy_connect_module        modules/mod_proxy_connect.so
#LoadModule proxy_ftp_module        modules/mod_proxy_ftp.so

Otherwise, would get various 0x800..... errors, after clicking on "Check for
Updates".

Anthony Albert
Comment 8 Brad Nicholes 2004-12-07 20:08:58 UTC
Reverted the patch that was committed for this bug.  It appears that it 
doesn't actually fix this bug and it breaks at least the TLS upgrade 
functionality by removing the content-length header for all 0 length 
responses.  Also, code for handling the "Content-Length: 0" header for HEAD 
requests is already being done in ap_http_header_filter().
Comment 9 Paul Querna 2005-05-27 21:13:56 UTC
*** Bug 35105 has been marked as a duplicate of this bug. ***
Comment 10 Bjoern Voigt 2005-05-28 16:04:37 UTC
I tested the Windows Update problem with newer versions of Apache2
(2.0.53+2.0.54). I can't find the "Content-Length: 0"-problem there. So it is
probably already fixed.

But Windows Update is still not working. I wrote about this in Bug #35105 which
was deleted, because it should be a duplicate of this bug.

Let's search for other reasons, why Windows Update is not working with Apache2
as a proxy.
Comment 11 Ralf Stubner 2005-06-01 19:48:32 UTC
(In reply to comment #10)
> I tested the Windows Update problem with newer versions of Apache2
> (2.0.53+2.0.54). I can't find the "Content-Length: 0"-problem there.

I have never seen "Content-Length: 0" comming from a apache proxy. However,
apache 2.0.53 as shipped with SuSE 9.3 still /removes/ the Content-Length
header completly. See #6 for a test case. Since this is the only difference
between the direct response and the response via the proxy server, I think
this is the reason why windowsupdate is not working.
Comment 12 William A. Rowe Jr. 2005-08-09 22:41:12 UTC
> I have never seen "Content-Length: 0" comming from a apache proxy. However,
> apache 2.0.53 as shipped with SuSE 9.3 still /removes/ the Content-Length
> header completly.

The proxy should, legitimately, yank the Content-Length header on the HEAD
request -IF- it will respond with Transfer-Encoding: chunked and without
the Content-Length: when the GET is processed.  So we need to perform this
same transformation (replace Content-Length: n with Transfer-Encoding: chunked)
on bodyless HEAD requests; the CL and TE headers then match what the GET will
do.  

But the only way to proxy a HEAD request when the client does not accept TE
responses is to proxy it as a GET and run it through the C-L filter to determine 
the size, if any content/body filters have been injected.
Comment 13 Greg Ames 2005-10-19 00:00:46 UTC
Created attachment 16741 [details]
patch #3

I've attached a new patch for this problem.  it is more narrowly scoped than
the previous patches to avoid problems.  it works fine for me.	

note that you also have to enable the CONNECT method 
( LoadModule proxy_connect_module modules/mod_proxy_connect.so )
to make Windows Update 100% happy.  thanks to Eric Covener for discovering
that.

rather than just commit it, I will post the patch to dev at httpd since
previous patches encountered problems and explain how I think this one avoids
them.
Comment 14 Joe Orton 2005-10-26 17:51:27 UTC
Patch was committed as:

http://svn.apache.org/viewcvs?rev=327008&view=rev

(backports to 2.0.x/2.2.x not submitted)
Comment 15 Joe Orton 2005-10-28 18:26:15 UTC
*** Bug 28571 has been marked as a duplicate of this bug. ***
Comment 16 Eric Covener 2011-09-17 19:53:23 UTC
*** Bug 39837 has been marked as a duplicate of this bug. ***