Filtering in a Dynamic Context
As it stands, the filter architecture presents problems when used
in with unknown content; either in a proxy or with a local handler
that generates different content types to order. The basic difficulty lies in the Apache configuration.
Content filters need to be applied conditionally: for example,
we don't want to pass images through an HTML filter.
The generic configuration directives for filters are:
- SetOutputFilter
- Unconditionally insert a filter.
- AddOutputFilter, RemoveOutputFilter
- Insert or remove a filter based on "extension".
- AddOutputFilterByType
- Insert a filter based on Content Type.
In the case of a proxy, extensions are meaningless, as we cannot
know what conventions an origin server might adopt. Neither is
AddOutputFilterByType (nor its hypothetical siblings such as
AddOutputFilterByEncoding or AddOutputFilterByLanguage) any use,
because the response headers from the proxy are unknown at the
time the filter is inserted and initialised. So we have to
resort to the unsatisfactory hack of inserting a filter
unconditionally, checking the response headers from the proxy,
and then having the filter remove itself where appropriate.
Examples of filters that will do this are mod_deflate, mod_xmlns,
mod_accessibility and mod_proxy_html.
