On Thu, May 30, 2002 at 07:34:00AM -0000, [EMAIL PROTECTED] wrote: > jerenkrantz 02/05/30 00:34:00 > > Modified: . CHANGES > modules/proxy mod_proxy.c proxy_http.c > Log: > Switch mod_proxy to using the brigade/filter calls directly rather than > the *_client_block calls.
Okay, with mod_proxy and the cgi variants done, I think I've transformed the majority of our uses of ap_*_client_block to natively use the input filtering API. (And, mod_deflate's new filter follows a similar strategy.) In case you are interested, here's a summary of what/why I've done: - These modules will now accept chunked encoding (which will be dechunked by HTTP_IN). Previously, this was forbidden due to ap_setup_client_block(). This is probably the major reason why I did this. I don't believe we should necessarily limit to only accepting C-L denoted bodies. As I've stated before, if a module wishes to get the raw chunks, they should remove the HTTP_IN filter. - As a side effect, a lot of 8k static buffer allocations have been removed. (I can hear the Netware guys cheering from here.) - This should also greatly reduce the number of copies that the input data should have to go through as it proceeds up to these modules. In the case of mod_proxy, the code is zero-copy from the standpoint of the module - it just gets a brigade from the input and passes it on to the output filter - no copies needed. - A large amount of code in the get_client_block can be bypassed. So, this should reduce our input overhead. And, we don't have to parse the header information twice for each request body (since we don't call ap_setup_client_block anymore). - As discussed previously on here (thanks to Greg and Aaron), HTTP_IN (aka ap_http_filter) will now handle the protocol logic for you. If there should be no body, it will return EOS. Note that due to the RFC interpretation, I had to introduce a special case for proxy's "response" using HTTP_IN so that the response case with just a "Connection: Close" would be deemed valid (this case is only valid when dealing with a response body). Please let me know if you encounter any problems or have any suggestions. I have tried to test all cases that I could think of (incl. httpd-test), but it's very possible something slipped through. -- justin
