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 16:21:31 GMT

In a message dated 00-08-17 15:24:33 EDT, Ryan writes...

Ok... I see where I have gotten totally confused about something.

I was looking at the patches and assuming that there must be
some reason that code one would normally expect to be there
was missing... but it's not. It's a choice.

I don't agree with the choices and I think they are going to bite
you in the ass but thanks for clearing things up.

See inline comments below.

>  > >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.
>  While I agree with that response, I would add something to it.  Installing
>  a filter, and calling the filter are two very distinct actions.  If a
>  filter is installed, then we have to call it.  If the filter itself
>  decides it isn't needed, or if it causes problems, then either that filter
>  needs to remove itself from the stack, or that filter needs to just pass
>  the data down.  We have never tried to protect people from poorly written
>  modules before, and I don't think any of us want to attempt to do it now.

"If a filter is installed..."

If the only criteria you are ever going to check as an installation
dependency is whether or not it simply exists then ignore just
about everything I said and good luck.

"If the filter itself decides it isn't needed or causes problems..."

WHEN does the filter get the chance to make that decision?

I, myself, was assuming that critical path was part of the
'installation' procedure itself but now I see that there is a big
difference between what happens at startup and what can
happen during runtime. 

"that filter needs to remove itself from the stack"

AND undo the output header changes already made, if any? How?
I agree that it should... I just don't see the rules emerging
for doing that.
>  > >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.
>  There will never be a case where headers will need to be modified in order
>  for a filter to be installed successfully.  

As long as 'install' only has to do with whether or not it exists, yes.

If all the 'smarts' about whether or not that filter will actually be able
to do anything at all with the current transaction are pushed into
the post-install processing then you should always get a good install.

I was simply assuming that some of the 'smarts' where going to 
be in the ap_add_filter() call. I see now that no such smarts will
be present. I don't agree with the simplistic approach you are taking.

I still think the filter code itself should get SOME kind of tap on the
shoulder and the ability to participate in a dynamic install request,
but that's just me.

It's a lot like saying that something is going to install a new window
on a GUI system and the user's window code itself is simply never going
to get the chance to see a WM_CREATE and return FALSE ( for
whatever reason ) which stops the window creation dead in its

You seem to be saying ( using this analogy ) that 'the window
will always appear if the procedure is found... nothing can stop it.

>  There may be a case where a
>  filter won't be installed until a certain header has been set, 

So you concede that the actual installation of SOME filters
MIGHT depend on a header value? This is what I have been saying.
I think this is going to crop up more often than you think.

>  example, take a look at chunking.  There may be cases where filters are
>  installed but they don't do anything unless a specific header value is
>  set, but installation always succeeds if it is a valid filter.B

'filters are installed but they don't do anything'.

Why suffer the overhead? If the filter can participate in the
dynamic installation itself and return a FALSE to stop the
install when it knows it's not needed then why not?

>  > >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.
>  Filter writers don't check anything during installation.  Filters can
>  check when they are run, but never when they are installed.  

That's pretty much it right there.
I understand that this is a design choice.
I just don't agree with it and I think you are not realizing 
the importance of dynamic filter installation on a pre-transaction
basis versus 'eternal' filters that are set up in a static config file.

> That is of course a small mis-truth.  Because it is most likely up to the 
> module itself to insert the filter, when inserting the filter, the module 
> do some checking, but that checking would be done outside of the filtering
> code.  The module would implement a function that did basic checking, and
> would either insert the filter or not based on the results of that check.

So now you are saying that there might ALWAYS be a 'user exit'
to a filter module but the decision to install rests with the module
itself? That would be closer to what I was picturing rather than
filters ALWAYS installing 'no question asked' and 'hanging around' 
even if they are unable to do anything because the current 
transaction's header fields don't meet minimum dependecies.

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

View raw message