Return-Path: Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 96577 invoked by uid 500); 2 Feb 2002 01:10:27 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Delivered-To: moderator for dev@httpd.apache.org Received: (qmail 75516 invoked from network); 1 Feb 2002 17:27:40 -0000 From: "RCHAPACH Rochester" Subject: Re: httpd 2.0 problem with ap_get_client_block To: dev@httpd.apache.org Cc: jerenkrantz@ebuilt.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Sender: "Kent Bruinsma" Date: Fri, 1 Feb 2002 11:27:38 -0600 X-MIMETrack: Serialize by Router on d27ml101/27/M/IBM(Release 5.0.9 |November 16, 2001) at 02/01/2002 11:27:39 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N So my post did show up... I thought it got lost, I sent it on Monday... Strange delay factor... I spent some additional time following the CVS's on this since last June and figured out what was going on. It is working, just not where I was initially looking. The module that was having this problem was calling ap_get_client_block 1 too many times. I was getting confused reading the comments in 2.0 because they still talk about r->remaining being important. Should have just read the code... Sorry for the confusion. Kent Bruinsma bruinsma@us.ibm.com On Mon, Jan 28, 2002 at 11:37:09AM -0600, RCHAPACH Rochester wrote: > We are experiencing a problem with ap_get_client_block where a module > (Tomcat in this instance) is calling ap_get_client_block() to read stdin > and the last read (the one where we get back 0 bytes) is hanging for > Timeout time before returning. I did some investigation in http_protocol.c > in ap_get_client_block and it talks about managing r->remaining. I checked > httpd 1.3.x and see that is does indeed manage this, but this logic is > missing from httpd 2.0. I am guessing that this may be part of a > work-in-progress based on the section in the status "revamp the input > filter behavior", but thought I would post to make sure it isn't being > overlooked. Well, it should work. I *believe* that httpd-test tests POSTs via ap_get_client_block, so... How is the body sent? Content-Length? Chunked? Or, Connection: Close? The idea is that ap_http_filter should be quickly returning when we have read past the end of the body. It sounds like ap_http_filter isn't detecting when EOS should occur. -- justin