You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Justin Erenkrantz <je...@apache.org> on 2002/05/30 10:23:07 UTC
Modules using the input brigade calls directly
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
Re: Modules using the input brigade calls directly
Posted by Cliff Woolley <jw...@virginia.edu>.
On Thu, 30 May 2002, Eli Marmor wrote:
> A small wish "from the field":
>
> Will Justin's stuff be included with the RC3 of 2.0.37?
I'm still procrastinating on tagging RC2. Most of Justin's stuff is
already in, but I'm considering backing it out and waiting until RC3 since
some questions have surfaced. I see no reason why it shouldn't go in the
final 2.0.37 though, assuming we get enough testing time on it between now
and then.
--Cliff
Re: Modules using the input brigade calls directly
Posted by Eli Marmor <ma...@netmask.it>.
A small wish "from the field":
Will Justin's stuff be included with the RC3 of 2.0.37?
--
Eli Marmor
marmor@netmask.it
CTO, Founder
Netmask (El-Mar) Internet Technologies Ltd.
__________________________________________________________
Tel.: +972-9-766-1020 8 Yad-Harutzim St.
Fax.: +972-9-766-1314 P.O.B. 7004
Mobile: +972-50-23-7338 Kfar-Saba 44641, Israel
Re: Modules using the input brigade calls directly
Posted by Eli Marmor <ma...@netmask.it>.
Justin Erenkrantz wrote:
>
> 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:
> ...
> ...
Wow, great! (*)
Finally, Apache completed the migration to the modular model of I/O
filtering...
A historical day that should be remembered! (*)
(*) (The first and the last paragraphs are NOT sarcastic...)
Thanks, Justin (I need no more patches in the core source of Apache...
Now I can do everything cleanly...)
--
Eli Marmor
marmor@netmask.it
CTO, Founder
Netmask (El-Mar) Internet Technologies Ltd.
__________________________________________________________
Tel.: +972-9-766-1020 8 Yad-Harutzim St.
Fax.: +972-9-766-1314 P.O.B. 7004
Mobile: +972-50-23-7338 Kfar-Saba 44641, Israel
Re: Modules using the input brigade calls directly
Posted by Dwayne Miller <dm...@espgroup.net>.
Which module would be a good example for someone who wants to rewrite an
existing
ap_*_client_block
based module?
Tks
Brian Pane wrote:
>On Thu, 2002-05-30 at 01:23, Justin Erenkrantz wrote:
>
>
>
>>- 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.
>>
>>
>
>Thanks, this is a great improvement.
>
>--Brian
>
>
>
>
Re: Modules using the input brigade calls directly
Posted by Brian Pane <bp...@pacbell.net>.
On Thu, 2002-05-30 at 01:23, Justin Erenkrantz wrote:
> - 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.
Thanks, this is a great improvement.
--Brian