> From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]] > > On Fri, Apr 12, 2002 at 02:22:03PM -0700, Ryan Bloom wrote: > > In your code above, there was no 100 Continue sent to the client. It > > also doesn't solve the problem for anybody who is using the > > ap_.*client_block API, as most modules do. Don't tell me that you can > > just send the 100 message yourself. That is a hack. > > Fair enough, you could add the 100-Continue logic to ap_http_filter. > That seems a good enough place for it. It wouldn't get called > until you are ready to read the body and that filter is supposed > to handle all of the HTTP protocol logic anyway.
I don't understand this. You are trying to remove an API that isn't broken, and that people have been using for years! At some point, grep through the httpd-2.0 code, looking for ap_get_client_block(). We use it 11 times in the server code itself. If the API is so broken that it is unusable, why is it that the server is still using it? Filters are not the solution for everything. In this case, it makes sense to have a common function that does all of the consumption. The idea that the http_protocol filter should be a monolithic filter that does everything is just wrong. It can't possibly know if we want to send a 100 Continue or not. Take a look at ap_discard_request_body, how are you going to work that into the filter? > > Part of what we owe our module authors is a clean API that makes writing > > an Apache module easy. The ap_.*client_block functions are easy to use, > > and they can solve the problem easily. More than that, they are what > > people are used to using from Apache 1.3. > > No, you are trying to hide the real interface with this old API. > 2.0 is a new world order. By hiding the real interface, you are > allowing errors and other issues to be silently or improperly > ignored. This is the real problem here - the CGI module has > no way of knowing whether the socket was disconnected or a > Limit was hit. And, the ap_*client_block API doesn't provide any > way to let errors propogate. -- Justin No, I am trying to provide a simple interface for users to use. The statement that "2.0 is a new world order" is just plain incorrect. Why are you so hung up on asking module authors to change every existing handler that wants to deal with body data? The function is going to remain in the server, because it would completely bork the API to remove it now. The function works, and it is widely used in ALL existing content-generating modules. Forcing a new API just to force a new API makes no sense, and shows no respect for module authors. Ryan
