C-L of proxy output (Re: [PATCH] Fix proxy's handling of input bodies)

[Sami Tikka <sa...@f-secure.com>]

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

Re: C-L of proxy output (Re: [PATCH] Fix proxy's handling of input bodies)

[Brian Pane <br...@cnet.com>]

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
objects.

Brian


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.