On Tue, 2002-12-03 at 05:04, Bill Stoddard 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. > > > > This patch changes it so that mod_proxy delays setting the > > Content-Length header until we have read the entire body from the > > filters and can recompute the C-L header. This is kind of icky, but > > there is no way around that if we're sending the C-L header. > > > > What we can do is either do non-keepalive connections > > This sounds a bit more reasonable to me. That is, send chunked if the client > will accept chunked, else send a connection: close header (which will tell the > client we are done sending). As a compromise, we could start off buffering and > if we hit some magic threshold and we still do not know the c-l, add a > connection: close header and start sending.
+1. Buffering up to, say, 8KB sounds good to me. For anything larger than that, there's little harm in sending Connection: close. Brian
