Like I said in my follow up post to my original, you don't even need to post the data to actually have this occur. I telneted to the server, and let it sit there for like 47 minutes before I killed it. I never had it time out.
-- Jon On Fri, Oct 26, 2001 at 11:51:59AM -0700, Ryan Bloom wrote: > On Thursday 25 October 2001 08:52 pm, Ryan Bloom wrote: > > > It seems that there is a possibility for DoS on Apache servers > > > when doing a POST. On search.apache.org, I can send the following > > > request: > > > > > > PUT / HTTP/1.1 > > > Host: search.apache.org:80 > > > Content-Length: 1000 > > > <newline here> > > > > > > And just let it sit there forever. search.apache.org is running 2.0.24, > > > and I'm running out of CVS and seeing the same behaviour. Seems bogus to > > > me. > > > > Well, after a few weeks of meaning to look into this, I finally have. Jon, > > you are 100% correct that this does happen. The problem is the > > handle_map_file handler. I have begun to track it down, but what is > > happening, is that the first request fails after the timeout is hit. The > > error page is requested, and that gets sent back to the > > ap_internal_redirect, but the content-length is still set, so the second > > request is hosed. Then we end up in an endless loop. > > > > I haven't really looked at how to fix this yet, and I have to write a part > > of my book tonight, but the first step is identifying the problem. This > > goes away if you remove all of the .var files from the config file BTW. I > > would suggest that if we don't fix ASAP, those lines should be removed from > > the apache.org site, and this MUST be fixed before we release the next > > beta. > > Had more time to look at this. It looks like we actually will timeout given enough > time, but by default that time limit is like 10 minutes. I think this can be fixed > by setting the content-length to 0 when we go to serve error pages. I am > attempting this now-ish. > > Ryan > > ______________________________________________________________ > Ryan Bloom [EMAIL PROTECTED] > Covalent Technologies [EMAIL PROTECTED] > --------------------------------------------------------------
