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
