On 26/02/2006, at 5:58 AM, Jim Gallacher wrote:

> Since we are discussing Python*Filter, can someone explain why it
> is only allowed in the server config context, whereas
> SetInputFilter and related directives are allowed in any context?
> Is this a mod_python feature or a bug, or is it just the way
> filters work?

There are two parts to it. First is the registration of a filter.
Second is saying that
that filter should be used within a particular configuration
container context.

The table used to hold the names of the registered filters is global.
Ie., shared
by the whole server (virtual server??). Because of this, it isn't
possible to say
that the registration of a filter can only be valid within a certain
context.

Although the registration is global, the filter still needs to be
associated with
specific requests using the Set*Filter directives. It is the latter
second step which
constraints it to a specific context.

Not being able to dynamically register filters for only a specific
context, is a bit
limiting, which is why I implemented:

http://issues.apache.org/jira/browse/MODPYTHON-103

With this, in 3.3 you can dynamically register filters implemented in
mod_python.

from mod_python import apache

def uppercase(filter):
s = filter.read()
while s:
filter.write(s.upper())
s = filter.read()
if s is None:
filter.close()

def fixuphandler(req):
req.register_output_filter("UPPERCASE","example::uppercase")
req.add_output_filter("UPPERCASE")
return apache.OK

You might as shown use a fixuphandler() to register a filter to
convert all content
to uppercase and then activate it for the current request.

Even if only static files are being served, they will still pass
through the filter.

The dynamic registration works by mod_python itself being registered
as a
filter under the name MOD_PYTHON on initialisation of mod_python. When a
mod_python filter is dynamically registered using
req.register_*_filter(), the
details are remembered in the per request config. When
req.add_*_filter() is called,
the MOD_PYTHON filter is attached to the request, with some context
being
supplied such that when it is called, it knows to actually delegate
to the
filter registered within the mod_python per request config.

Graham

[ Post a follow-up to this message ]