httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <grega...@remulak.net>
Subject Re: httpd 2.0 problem with ap_get_client_block
Date Fri, 01 Feb 2002 17:55:48 GMT
Justin Erenkrantz wrote:
> 
> 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?

ooooh...chunked...it could be broken on ebcdic boxes now, due to the changes in
the input filtering and ap_getline.  It used to be that every byte of inbound
http protocol data went thru ap_getline and got translated if the source code
charset wasn't ascii.  I don't know if that's true for chunk headers any more.

We also had some breakage with long timeouts for POSTs on all platforms a while
back, I think before 2_0_28.

Kent, what level of base Apache are we talking about here?

Greg
 
> 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