httpd 2.0 problem with ap_get_client_block
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. Kent Bruinsma [EMAIL PROTECTED]
Re: httpd 2.0 problem with ap_get_client_block
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
Re: httpd 2.0 problem with ap_get_client_block
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? h...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
Re: httpd 2.0 problem with ap_get_client_block
On Fri, Feb 01, 2002 at 12:55:48PM -0500, Greg Ames wrote: h...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. Yeah, I think EBCDIC boxes may be broken in ap_rgetline. I posted asking for people with those boxes to give feedback. No one responded. I don't think not having EBCDIC support would stop a beta or even a GA perhaps. =) I will add an item to STATUS about the EBCDIC now to remind us that it may not work. -- justin
Re: httpd 2.0 problem with ap_get_client_block
Justin Erenkrantz wrote: On Fri, Feb 01, 2002 at 12:55:48PM -0500, Greg Ames wrote: h...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. Yeah, I think EBCDIC boxes may be broken in ap_rgetline. I posted asking for people with those boxes to give feedback. No one responded. all the 2.0 ebcdic guys I know have been kinda busy lately... I will add an item to STATUS about the EBCDIC now to remind us that it may not work. -- justin It might be a piece of cake fix. Is it true that inbound chunk headers no longer go thru ap_[r]getline? Greg
Re: httpd 2.0 problem with ap_get_client_block
Greg Ames wrote: Yeah, I think EBCDIC boxes may be broken in ap_rgetline. I posted asking for people with those boxes to give feedback. No one responded. It might be a piece of cake fix. Is it true that inbound chunk headers no longer go thru ap_[r]getline? (yeah I know, find and grep are my friends.) I just eyeballed ap_http_filter, and it looks like every inbound chunk header is still read via ap_getline, so that part looks fine. Greg
Re: httpd 2.0 problem with ap_get_client_block
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. Kent Bruinsma [EMAIL PROTECTED] Just got off the phone with Kent. He called me because he's got a 4 day outbound email lag before his posts show up on the list (???) and wanted to save us some time. This turned out to be a Tomcat bug. It was calling ap_get_client_block an extra time, causing an extra read which timed out. He's working on 2.0.31 or something close, and ebcdic translation is still working fine. He had to work his way thru the input side code in order to figure out what was happening, and liked the look of the code. So congratulations, Justin, nice job! Greg
Re: httpd 2.0 problem with ap_get_client_block
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
