httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject [Fwd: Modules using the input brigade calls directly]
Date Fri, 31 May 2002 18:14:44 GMT
something that we should also do when completing the port to 2.0.

-------- Original Message --------
Subject: Modules using the input brigade calls directly
Date: Thu, 30 May 2002 01:23:07 -0700
From: Justin Erenkrantz <jerenkrantz@apache.org>
Reply-To: dev@httpd.apache.org
To: dev@httpd.apache.org
References: <20020530073400.16561.qmail@icarus.apache.org>

On Thu, May 30, 2002 at 07:34:00AM -0000, jerenkrantz@apache.org 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

-- 


__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


Mime
View raw message