httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "RCHAPACH Rochester" <rchap...@us.ibm.com>
Subject Re: httpd 2.0 problem with ap_get_client_block
Date Fri, 01 Feb 2002 17:27:38 GMT

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






Mime
View raw message