httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <>
Subject Smart filtering Module
Date Sat, 28 Aug 2004 12:05:38 GMT

I posted my proposed smart filter module a few days ago, in response
a post here identifying a situation where it is relevant.

I have now completed a first version of the accompanying manual page.
I attach:
	Two images used to illustrate the module
I've also uploaded the HTML to .

I believe I have addressed the concerns raised when I mooted the idea
of this some weeks ago:
  * Existing filters are binary-compatible with the new module
  * I've restored the filter_init handlers to the architecture
  * I've retained my proposal to enable dealing with aspects of
    the HTTP protocol on behalf of filter.  However, the default
    is always for the filter harness to do nothing, and leave the
    filter provider (a content filter module) to deal with that
    as before.

Working code and documentation (modulo bugs and TODOs) should help
demonstrate the purpose and utility of the proposal, and move the
discussion forward.  I'd like to offer this as a contribution to the
core httpd distribution, to be included as standard in 2.2.

What is currently implemented is the basic architecture as described
before.  Configuration is fully dynamic, with my proposed set of
configuration directives now implemented.

Note that the module only applies to output filters and will only
work with AP_FTYPE_RESOURCE or CONTENT_SET filters.  I don't see a
need for this functionality elsewhere (but I'm open to persuasion:-)

The main TBD is an ap_filter... API interface for other modules to
work actively with it.  To implement that, I will need to merge the
ap_filter_rec_t structure into the mod_filter_rec.  This will be
binary back-compatible (the new fields go on to the end of the
ap_filter_rec_t), but will of course require commits to code outside
the module, specifically util_filter.

A second TODO is to enable mod_filter to run as a provider for itself.
The purpose of this is to enable chaining of configuration rules beyond
what we can already do by setting an environment variable with
mod_rewrite and dispatching on an "env=" variable (example: insert
DEFLATE depending on both Accept-Encoding request header and
Content-Type response header.  mod_rewrite can't do that because
it runs too early to be sure to have the response headers).

Nick Kew
View raw message