httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [PATCH] ap_add_filter
Date Thu, 17 Aug 2000 12:53:45 GMT
In a message dated 00-08-17 12:18:48 EDT, you write:

> This is a real patch to ap_add_filter.  The basic idea, is to add filters
> in a stack instead of the queue that we are currently using.  The
> difference, is that filters can specify a filter to be added after.  That
> is incredibly unclear, so let me explain.  :-)

It's not incredibly unclear. Makes perfect sense and is SOP
for filtering. The NDIS driver stack uses the same approach.

Only a filter itself should know what comes AFTER
it. Knowing what should come BEFORE it is obviously
doable as well but a bit more complicated.

I think you are going to need a 'type' check on the insert.

In other words... only filters of a certain TYPE can 'insert'
filters of the SAME TYPE immediately after themselves
or your stack might get messed up. I don't see any filter
type checking in the patch.

CONNECTION filters can insert another CONNECTION
filter immediately after themselves but if a CONNECTION
filter tries to insert a filter of another type it gets real
complicated first time out.

I know this is just a 'first pass' and all but I also don't see
any way to 'back out' once the process has started.
Example: What if a CONNECTION filter does try to insert
some other type of filer immediately after itself and, since
this might not be allowed, the add filter function fails and
returns an error... where is the code to restore the headers
and simply continue without the filtering added?

Perhaps you could use the 'Santa Claus' approach used
by many other API's. It's the 'Checking it once checking it
twice' approach.

Any time a filter is going to be added it needs to simply
ATTEMPT to do it ( checking it once ) and then check
the return code. The first check actually does nothing
but make sure that all WILL go well and the filter addition
will, in fact, succeed... but nothing has really happened
to alter the processing chain (yet). If the return code is
OK only then are the output headers altered and the
REAL filter insertion call takes place. ( second part of Santa
Claus approach ).

If the return code on the first ( checking it once ) call FAILS
then no harm done. The filter has not really been installed
yet and the headers are left alone. Nothing has to be 'undone'
because the filter didn't even get installed.

Your original code...

    if (r->chunked) {
         apr_table_mergen(r->headers_out, "Transfer-Encoding", "chunked");
         apr_table_unset(r->headers_out, "Content-Length");
         ap_add_filter("CHUNK", NULL, r, NULL);

then looks like this...

   if (r->chunked) {
         /* Check and see if the filter insertion we want to do will 
succeed... */
         if ( apr_add_filter("CHUNK", NULL, r, NULL )
             /* Yes... it will succeed... so go ahead and alter the headers */

         apr_table_mergen(r->headers_out, "Transfer-Encoding", "chunked");
         apr_table_unset(r->headers_out, "Content-Length");
         ap_add_filter("CHUNK", NULL, r, NULL);

Kevin Kiley
CTO, Remote Communications, Inc. - Online Internet Content Compression Server.

View raw message