httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@ntrnet.net>
Subject Re: cvs commit: httpd-2.0 STATUS
Date Fri, 07 Jun 2002 02:29:33 GMT

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


Mime
View raw message