Return-Path: Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 22045 invoked by uid 500); 7 Jun 2002 02:30:35 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 22032 invoked from network); 7 Jun 2002 02:30:34 -0000 Date: Thu, 6 Jun 2002 22:29:33 -0400 (EDT) From: Ryan Bloom To: dev@httpd.apache.org Subject: Re: cvs commit: httpd-2.0 STATUS In-Reply-To: <20020606190445.J8224@lyra.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N ++1 to everthing in this e-mail. Thank you Greg, you have just stated everything that I have been thinking for sometime. Remember when I tagged 2.0.33? I did that without any notice to prove that it could be done without a four week discussion on-list. Granted, we didn't release that version, but it was better than the previous tag, so we could have if we had wanted to. Ryan On Thu, 6 Jun 2002, Greg Stein wrote: > On Fri, Jun 07, 2002 at 12:59:03AM -0000, jerenkrantz@apache.org wrote: > > jerenkrantz 2002/06/06 17:59:03 > > > > Modified: . STATUS > > Log: > > Clarify note on ap_discard_request_body(). If we want to change it, > > we should do it before .37 - hence its remaining as a showstopper. > > Why "should" we do it before .37? I see no possible explanation for it being > a showstopper to a .37 release. > > Releases can't be perfect. Stop holding up the damned thing. Get something > into people's hands. It is more of a disservice to users to keep them back > on .36 than to give them a .37 today. > > If you're about to say, "but if we deferred it, it would change the API in > .38" So? Like we aren't ever going to change the API? And even so, we don't > *have* to remove the function from the API. We can simply delete the > contents of the function. Let users keep calling it from their code. It just > won't happen to do anything. > > Are you suggesting that potentially flaky behavior on edge cases make this a > showstopper? That definitely isn't a showstopper. > > About the only possible reason for a showstopper is that it could be used as > a Denial of Service, by some kind of bug in there making the server crash. > But I've already stated before that (as a DoS), that is a poor attack. A > much more successful attack is to simply open a ton of connections, up to > Apache's limit. Nobody else can get in, until Apache times out the > connections. Heck, the attacker could also trickle in a byte at a time to > make it seem like a request is arriving, and resetting the timeout clock. > > So... why a showstopper? Why hold up .37? Let's hear it. > > Cheers, > -g > > p.s. sometimes, it almost makes me feel like getting off my ass and snapping > a .37 and releasing it just to show that we *can* make releases a hella > lot easier and more frequently. but since I'm not, and the people who > *are* making releases choose to use a convoluted process that takes two > or more weeks to simply snap a tarball... well. who am I to say? > > p.p.s. "wah wah. we're GA. we can't just release any old tarball." bullshit. > release it and call it an alpha for upcoming fixes and functionality > to the GA release. "people experiencing specific problems with the > .36 release may choose to use this one, but the HTTPD group has > chosen not to certify it as a GA release (yet)." > > -- _______________________________________________________________________________ Ryan Bloom rbb@apache.org 550 Jean St Oakland CA 94610 -------------------------------------------------------------------------------