httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <>
Subject Re: Stripping Content-Length headers
Date Sun, 05 May 2002 21:02:30 GMT
On Sun, May 05, 2002 at 01:17:28PM -0700, Justin Erenkrantz wrote:
> On Sun, May 05, 2002 at 12:54:37PM -0700, Roy T. Fielding wrote:
> > It is legal, but not advisable.  It is not better to use chunking than
> > it is to use C-L.  C-L works better with HTTP/1.0 downstream and allows
> > progress bars to exist on big downloads.  Any filter that does not
> > transform the content should not modify the C-L.
> The C-L filter has logic that if we are ever passed more than
> 32000 bytes (4 * AP_MIN_BYTES_TO_WRITE) and we're HTTP/1.1
> downstream, we use chunked encoding.  Otherwise, we'll use
> C-L.  Or, if a flush bucket is ever sent, we'll use chunked.
> This is the way the entire server operates (regardless of
> proxy).  -- justin

Actually, to correct myself, that isn't exactly true.  It has to do
with the convoluted conditional in ap_set_keepalive() mixed with the
C-L filter.  The partial send in the C-L filter doesn't directly
imply that we'll use chunked, but we'll use chunked if there was no
C-L header set (but the C-L filter won't be setting it when doing a
partial send - it had to be there before the filter started).  This is
due to the ap_set_keepalive() r->chunked = 1 side-effect.

Here's my question: why is C-L filter even getting involved if there
is a C-L header?  Why shouldn't it just get out of the way if there
is a C-L already present?  Why do the duplication?  Should we assume
that any module that changes the content is smart enough to unset it?
Perhaps we can't do that - a module might change the content but not
unset C-L?  -- justin

View raw message