On Fri, Apr 12, 2002 at 04:37:58PM -0700, Aaron Bannert wrote: > 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.
You must have missed my post where I outlined ap_get_brigade() calls. I think that's the proper way to deal with reading request data. I believe that strategy matches the rest of our server's architecture (uses buckets/brigades). > 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.) Yes, as I have repeatedly mentioned, if a filter were to use the strategy I outlined (which can be done right now - perhaps with the exception of the 100-Continue stuff which could easily be moved into HTTP_IN I think), they will be broken since the Limit directive will not be respected. -- justin
