httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <>
Subject Re: C-L of proxy output (Re: [PATCH] Fix proxy's handling of input bodies)
Date Thu, 05 Dec 2002 03:23:43 GMT
There was some discussion about this a few weeks ago, under the
subject "mod_cache and multiple brigade."  It does seem to be a
bug that mod_proxy is removing the content-length.  I'll commit
a fix to the 2.1 branch tonight and port it back to 2.0 if nobody


On Tue, 2002-12-03 at 12:12, Sami Tikka wrote:
> 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.

View raw message