> -----Original Message----- > From: Eric Covener [mailto:[email protected]] > Sent: Montag, 25. August 2014 22:05 > To: Apache HTTP Server Development List > Subject: PR56729: reqtimeout bug with fast response and slow POST > > I am looking at this PR which I was able to recreate: > > https://issues.apache.org/bugzilla/show_bug.cgi?id=56729 > > mod_reqtimeout thinks the body is still being read when it gets called > with mode=AP_MODE_SPECULATIVE during check_pipeline() near the end of > a request > > Since all of the handlers processing time has gone by, it thinks the > read of the body has timed out and it returns an error, setting > AP_CONN_CLOSE and a short linger time. > > Since mod_reqtimeout is below the protocol level(AP_FTYPE_CONNECTION + > 8), it cannot even see the HTTP input filters EOS bucket if it's > looking for it. I was able to add a 2nd filter that shares the > conn_config with the normal filter and sits up higher looking for the > EOS -- this seems to work > > http://people.apache.org/~covener/patches/2.4.x-reqtimeout_post_error.diff > > But it seemed a little hokey, but I didn't really understand if we > could instead treat that speculative read as some kind of reset point > and couldn't think of any other hook to tell reqtimeout to bail out. > > Any alternatives?
I thought about to look out for an EOR bucket in an output filter. But your approach seems better as it detects faster the end of the input stream. Speculative reads might be also used by the handler for some reason. So I don't think they can be used as a signal to the mod_reqtimeout filter. OTOH speculative reads are not handled by the HTTP_INPUT filter. Hence if a handler uses a speculative read it doesn't get the dechunking from the HTTP_INPUT filter if applicable. This only seems to make sense if the handler doesn't handle with any possibly chunked body for whatever reason. Regards Rüdiger
