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 [EMAIL PROTECTED] 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
