Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Subject: RE: [PATCH] Fix proxy's handling of input bodies
From: Brian Pane <brian.pane@cnet.com>
To: dev@httpd.apache.org
In-Reply-To: <JHEPKCEMGPKFFDHHDDKDGEDDGEAA.bill@wstoddard.com>
References: <JHEPKCEMGPKFFDHHDDKDGEDDGEAA.bill@wstoddard.com>
Content-Type: text/plain
Organization: 
Message-Id: <1038931856.2841.2.camel@desktop>
Mime-Version: 1.0
Date: 03 Dec 2002 08:10:56 -0800
Content-Transfer-Encoding: 7bit

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