content processing modules ready for experimentation

The rbcollins_filters branch now has a interface to filters that has passed the changing-minute-by-minute phase.

Note: I've called it content processing, because filters do not need to alter the data to be useful: for example calculating the
checksum for signed digest responses is a perfect filter that won't alter the data and shold only be in the request chain when
needed.

Second Note: As I started adding the fourth! set of module code to squid (fs/repl/auth/filters) I figured that maybe it was time to
make generic modules that register with squid for the tasks they are able to be used for. Thus eliminating the need for a fifth set
of identical configure options, modules.sh etc. So this branch has the beginings of a generic module framework. This doesn't affect
the stability of the filters code, and if/when I start looking at bring the fs/repl/auth modules into the generic framework, I will
branch off HEAD and port over the relevant bits beforehand. It's into there that I am considering working on dynamic modules..
anyone think that dynamic modules are a good thing/bad thing?

So Joe & Moez, it's ready to be experimented with by you guys.

Features:
new squid.conf options:
http_reply_access
->this isn't strictly speaking a filter feature, it was a 'freebie' that occured to me while building the reply_filter_access code.
filter_add
filter_config
reply_filter_access
->These combined to create an instance of a filter, configure the filter, and apply it to a reply.

new acl type:
acl foo rep_mime_type [-i] regex
->is a regex acl used to determine whether to apply a filter to a reply body.

My sample filter (yes the code is garbage there, but I needed something to test with) called textreplace should act as a fairly
comprehensive template.

There's still a long list of things I need to do to call this stable, such as
* tidy up the boundary conditions for failed connections, aborted or dropped network connections etc.
* flesh out the filter framework with some functions for common code patterns.
* perhaps add a rep_status acl type?

Writing filters:
make a new directory in src/modules with the name of your module.
Copy over the makefile.in from src/modules/textreplace & edit the Module line at the top and the list of objects.
drop your source code into the same directory.

Add a function of type MOD_INSTALL called
mod_install_modulename
to your source code.

For filters, the install routine should call filterRegisterModule with the namestr passed to it upon install, and static pointers to
it's filterAddInstance and filterRemInstance functions.
Then implement all the functions contained in the FILTER_instance & FILTER_list structs.
Voila, have a champagne.

Rob
Received on Tue Jan 30 2001 - 04:21:29 MST