httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <>
Subject Modules using the input brigade calls directly
Date Thu, 30 May 2002 08:23:07 GMT
On Thu, May 30, 2002 at 07:34:00AM -0000, 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

View raw message