httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: [PATCH] fix LimitRequestBody for all input handlers
Date Fri, 12 Apr 2002 23:37:58 GMT
On Fri, Apr 12, 2002 at 04:29:27PM -0700, Justin Erenkrantz wrote:
> Precisely because people haven't gotten around to it.  Just
> because we went GA doesn't mean that the server is perfect.
> There are lots of APIs that we could optimize or enhance.
> I am merely pointing out that I think this is an API that we
> would be better off living without.  In retrospect, I should
> have removed these functions while I was cleaning up the input
> filtering.  This would have brought this issue up sooner, but
> now that we are GA, this API can't be changed.
...
> I believe the breakage that Aaron is seeing is because that
> API is fundamentally broken.  If you wish to cling to the 1.3
> API, fine with me.  I think we will end up hurting ourselves
> by trying to stick with the old APIs forever.  Our entire
> server is built around buckets and brigades - trying to isolate
> the modules from them seems to me like a lost cause.
> 
> I now don't care what you end up doing, but Aaron's patch is not
> the right solution.  If you wish to come up with a solution that
> maintains the old API, go ahead.  My only caveat will be that
> you can not break the filters in the process.  I believe it must
> be permissible for a module to rely on the filters to enforce
> HTTP compliance not a 1.3-compatible API that doesn't understand
> buckets and brigades.  -- justin

If you have a better way to deal with this, I *strongly urge* you to
make a proposal. If the API you propose is better than what we have now
I see no reason why we wouldn't make the change. Just because we've gone
GA doesn't mean we can't try to fix what's broken, even if it means some
work for our module authors. Of course, the amount of work we impart on
our module authors must be justified.

In the mean time, assuming for now that we will stick with these
old APIs for the forseable future, do you see any technical reason
why my patch shouldn't be committed? (I did some pretty good testing
of it, but I can't test everything.)

-aaron

Mime
View raw message