httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Marr <gr...@alum.wpi.edu>
Subject Re: [PATCH] ap_add_filter
Date Thu, 17 Aug 2000 19:01:51 GMT
At 02:27 PM 08/17/2000, TOKILEY@aol.com wrote:
>Because, given the current design approach, to actually ADD some 
>filters the headers ( and/or the request rec itself )  might already 
>need to be 'set up' with certain values or the install won't work.

ap_add_filter doesn't do anything that even remotely looks like 
that.  It simply inserts a filter in the stack.

>Even the approach I suggested won't work for certain types of 
>filters and there might need to be some 'fake' changes made to the 
>headers just to even check and see if the install will succeed and 
>someone ( or something ) is going to have to put the headers back 
>the way they were if the install fails and there have already been 
>filter-specific changes made to the headers.

No headers are checked during the installation of filters.

>Indeed... what if the filter install actually succeeds but then the 
>filter goes belly-up when the first data bucket arrives.

Then it's a poorly-written filter and shouldn't be used.

>See above. Given the current design and the fact that some filters I 
>can imagine will actually NEED the header changes made before the 
>install will succeed I think the 'check first' approach makes the 
>most sense.

The install will succeed if there is a filter in the system with that 
name.

>It depends. Even if the filter didn't install... what restrictions 
>and rules are there about it 'touching' the headers during the 
>install and then 'undoing' those changes if the install craps out 
>for some other reason?

Nothing is touched during the install except for the filter stack.

>At what point during the installation of a filter does the filter 
>writer himself get to make sure that all the resources that are 
>needed are available

Before the module that provides the filter makes the filter available 
by calling ap_register_filter, I would assume.  If it's available, it 
must be functional.

>At what point during the installation of a filter does the filter 
>writer himself get to make sure that ... the Inbound user-agent is 
>compatible with the filtering itself?

never

>Does the absence of any dependency constitute a FAILURE at the point 
>we are focusing on or does that kind of stuff have to wait until the 
>data starts arriving and only then can the 'guts' of the filter 
>decide to REMOVE itself ( and undo the headers ) if something goes 
>wrong.

If there's a chance that a filter may not be applicable, then either 
the filter installer needs to check for that condition before 
installing, or installer needs to just install the filter and let the 
filter itself modify the headers once it is determined that the 
filter is applicable.

>In other words... where is the real 'Are we going to be able to do 
>this?' code for filter installation(s) and what is the actual 'tear 
>it all down and undo everything' back-out procedure?

There isn't any, and there shouldn't need to be.  If a filter is 
installed and it finds it can't do anything, it should either 
uninstall itself or just become transparent.  Since I don't see 
anything for uninstalling, it should just become transparent and pass 
everything through unchanged.


--
Greg Marr
gregm@alum.wpi.edu
"We thought you were dead."
"I was, but I'm better now." - Sheridan, "The Summoning"


Mime
View raw message