Return-Path: Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 96461 invoked by uid 500); 3 Dec 2002 20:12:56 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 96448 invoked from network); 3 Dec 2002 20:12:55 -0000 Message-ID: <3DED104A.6020605@f-secure.com> Date: Tue, 03 Dec 2002 22:12:58 +0200 From: Sami Tikka User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@httpd.apache.org Subject: C-L of proxy output (Re: [PATCH] Fix proxy's handling of input bodies) References: <2147483647.1038876761@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Dec 2002 20:12:58.0381 (UTC) FILETIME=[5F7C23D0:01C29B08] X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Justin Erenkrantz wrote: > Currently, mod_proxy falls down if a filter is in the input chain > that changes the content of the original request. It will send the > original Content-Length not the size of the data it actually sends. > If the request was originally chunked, but the data it actually sends > isn't chunked (it sends no C-L header in this case). Oops. I have been wondering about similar thing in the output side of the proxy. In proxy_http.c line 899 Content-Length and Transfer-Encoding headers are deleted. Later the CONTENT_LENGTH output filter attempts to compute the content length the first time it is called but it fails if the content is not all there in the current bucket brigade. Most of the time the proxy is streaming data in small brigades containing just one bucket, which means the CONTENT_LENGTH filter is unable to compute the content length, which means the Content-Length header will be missing and data is terminated by closing the connection. Is it really necessary to remove the Content-Length header? Why cannot it be left there? If a filter is going to change the length of the data, that filter could then adjust the Content-Length header accordingly, or delete it if it cannot compute the new length before headers are transmitted. I can create a fix but it would be nice to know if the proxy was _designed_ to work this way and leaving the C-L header intact would create more problems elsewhere. Thanks for any insight you can provide. -- Sami Tikka tel: +358 9 2520 5115 Senior Software Engineer fax: +358 9 2520 5013 F-Secure Corporation http://www.F-Secure.com/ F-Secure: Securing the Mobile Enterprise