httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From TOKI...@aol.com
Subject Re: [PATCH] ap_add_filter
Date Thu, 17 Aug 2000 17:12:42 GMT

Ryan...

Above and beyond the call of duty... but thanks.

Save that email for the filtering FAQ. It was a 
the first ( and only? ) clear explanation of what
seems to be the consensus following the 
Frisco meeting.

But let's rewind the tape of emails for a second
and return to the one question that even your
excellent summary doesn't address...

If a filter is now allowed ( as I think it should be )
to insert ANOTHER filter immediately AFTER
itself... where is the TYPE checking in 
ap_add_filter() and where is the code that makes
sure the mixing and matching of CONTEXT 
versus TRANSPORT filter types stays straight?

My suggestion for a quick roll-out is to simply set
a rule which says 'A filter may add another filter
immediately after itself but only if that new filter
is the same TYPE'. 

I still think that adding any filter of any type after
one's own filter should be do-able and the ap_xxxx
calls are the ones that need to keep the actual
call chain straight... but for now the easiest thing
to do is limit the insertions to filters of the same TYPE.

I mean... am I dreaming here or what?

Since the scheme seems to be a kind of OSI soup
that allows a mix of both PRESENTATION level
filters and TRANSPORT level filters... don't they
all need to be 'in a straight line' but certainly all
within the same group? ( All PRESENTATION
filtering needs to occur before even the first
TRANSPORT filter kicks in? ).

Yours...
Kevin Kiley
CTO, Remote Communications, Inc.
http://www.RemoteCommunications.com
http://www.rctp.com - Online Internet Content Compression Server

Mime
View raw message