httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: cvs commit: apache-2.0/src/main util_filter.c
Date Thu, 17 Aug 2000 01:49:47 GMT

Greg, you are missing the design as I wrote it in my initial e-mail.  This
was a hack to get things working for chunking.  The real patch will take
more time.  Right now, we are completely broken, and it is impossible to
add more filters in the middle of processing.

On Wed, 16 Aug 2000, Greg Stein wrote:

> As I've said, this simply reverses the problem. Now the situation is that
> the LIFO makes it easy to insert *some* types of filters and harder for
> others. That is exactly where we were before.

It doesn't reverse the problem, it begins to solve it.  We should be a
stack.

> 
> You wanted an example: a PHP filter decides that it will generate SSI text
> and wants to add an SSI filter. With the original add_filter, this will come
> afterwards.

Not, we are a stack.  As you run a filter, when you insert the next one,
it gets inserted in the correct place.  The PHP filter would have been
inserted into the chain in the correct spot.  Basically, it would have
been:

default handler -->  PHP --> core_filter

becomes:

default handler -->  PHP --> INCLUDE --> core_filter

Thie behaviour is seen because we are a stack.  Traversing the stack has
the effect of popping the filters.  This wasn't coded, it was explained in
e-mail.  I started the work by making things LIFO.

> Another: let's say that we create ap_set_content_type() and let it add
> filters based on content type. (Ken seems to not like this one because of
> the need for magic MIME types, but let's go with it right now)  When
> mod_mime calls ap_set_content_type() to set the PHP magic type, we grab that
> and add a PHP processor. Next, we look in our config to see that all PHP
> output should be run though SSI. So we add an SSI processor.

All handled in the design.

> For the issue that you're seeing with chunking vs core, the filter type was
> designed to deal with this problem. The ordering of the hooks is the basis
> for simple ordering.

It's the wrong solution.  It requires that people make a decision about
what kind of filter they have.  As filter chains become more complex, we
need to start adding more types of filters.  We had five to begin
with.  The first three were content filters, and if they were called in
the wrong order, the result was wrong.

By using a stack, and inserting the filters as they are required, we solve
all of these problems.  

> This LIFO thing? Now the add_filter is COMPLETELY BACKWARDS for the
> insert_filter hook.
> 
>     ap_hook_insert_filter(my_hook, ..., AP_HOOK_MIDDLE);
>     ap_hook_insert_filter(my_other_hook, ...., AP_HOOK_LAST);
> 
> Guess what? my_hook will run first, but the filter will go in *after* the
> filter installed by my_other_hook.
> 
> Every filter writer would need to compensate with their insert_filter hook
> to reverse the sense. This is just too much.
> 
> The chunking filter can be fixed by using the appropriate filter types. Not
> by reversing the insertion.

It's not too much, because it isn't an issue.  There are two ways to
insert a filter.  1)  It is inserted from the config file.  2)  It is
inserted from code.  The filters inserted from the config file are in the
correct order, because that is how the admin wants them.  Filters inserted
by code are in the correct order because of when they are inserted.  The
only time this is a problem at all, is if the core filter isn't inserted
first.  This problem goes away because we can ensure that it is inserted
first.

Basically what I am saying is that our first step was wrong.  The insert
filters hook was wrong, and the FIFO is wrong.  Roy has been right all
along, because its the only way that works into the future.  You add
filters it is determined that they are necessary, and because of the way
the server works, this just works.

Relying on using the insert_filters hook is what is causing all of the
problems with filter ordering.  Most modules won't know if they should be
inserting filters during the insert_filters hook.

Ryan


_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------



Mime
View raw message