httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: BIG filtering patch.
Date Sat, 08 Jul 2000 03:43:18 GMT

> >I'm with Ryan on not understanding how a "stack" would work in the Apache
> >execution environment. I much prefer the types of ordering mechanisms that
> >are in mine and Ryan's patches. (I disagree with his using ap_hooks to do
> >it, but will take it over a stack any day :-)
> >
> >I'll also point out that my ap_add_filter() adds filters "at the end"
> >(meaning "after") of the particular group. In other words, a content filter
> >can add a filter and be guaranteed it will be inserted after "self".
> A stack is simply a linked list of filters in which you are only allowed
> to directly access the top filter.  In other words, it is the same thing
> you implemented except with a more recognizable interface.

Ahhhhhhh......  I see how a stack would work.  I have some questions, then
I'll outline my current plan.  :-)

> My notion of filters is always data driven, so it is more natural to
> have the filters added and removed at run-time based on the current
> data stream rather than the processing of modules.  Among other things,
> it isolates knowledge (and assumptions) about the protocols to the
> protocol layer rather than spreading it around every module.
> An interesting use-case to consider is the processing of multiple
> requests, where only the last layer knows that the "result" is
> actually a multipart MIME file being sent via e-mail.  It could
> be a multipart/mixed of application/http encoded HTTP/1.1 messages,
> or it could be a multipart/related of MHTML encoded files.
> How does the core decide how many times (and when) it should
> run the encoding filters?

Okay, so how does this work?  When does a module get to insert it's filter
onto the stack?  I can see how this works if the modules know about
each other, but I have a hard time envisioning this in the Apache
framework.  Can we take a real world example and walk through it so I can
understand this?  Let's take the obvious case of a CGI outputing include

In the two schemes implemented so far, we add another call to
ap_run_insert_filters(), or maybe to another filter insertion
routine.  Mod_include then inspects the content-type and sees that it
needs to search the data, so it installs it's filter in the content filter
phase.  When mod_cgi calls ap_pass_bucket, we end up calling
include_filter, which then calls ap_pass_bucket, which calls core_filter
to output to the network.

In the stack scheme, I would assume that everything would be the same,
except that ap_pass_bucket would always just take the top
element.  Hmmmm.....  That could work.

My current plan.  The current patch almost works.  There are one or two
bugs.  Currently, all the patch does, is insert a mmap bucket from the
core_handler, and then the core filter outputs it to the network.  Once
this patch is done, I will post it to the list.

Then I stop working for the night, and start doing some other
stuff.  Tomorrow I am spending the day with my wife.  Tomorrow night, I
will attack the filter patch again.  All I will be doing is replace the
filter registration code.  My original plan was to replace it with the
stuff from Greg's patch.  I am changing my mind to replace it with a stack
implementation.  If I am correct, it will require the re-implementation of
three functions, so it will be easy.  This will prove that the
registration stuff can be easily changed later if need be.  I will then
post my second patch.  This should happen late tomorrow night or Sunday

Once both patches are available, we can decide which to commit.  My
current leaning is towards the stack implementation (assuming I can make
it work).

Hopefully, we'll have VERY rudimentary filtering in the server sometime
Sunday or Monday.

Does this plan make sense to everybody?


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message