Protocol Handling
The business of a content filter is to deal with content. As far
as possible, it should not be concerned with details of the HTTP
protocol. Yet the presence of a filter may affect the response
headers.
At this point, we need to make a distinction. Some modules are
closely tied with one or more HTTP header: for example, mod_deflate
affects Content-Encoding, or an XSLT transform affects Content-Type.
Such cases are clearly the responsibility of the filter itself, and
the current level of abstraction (apr_table) is appropriate.
But in some common cases, headers are affected as a by-product of
a filter. Examples are Content-Length, Content-Range, ETag, and
Warning. It is wasteful and error-prone for every filter to have
to deal with these headers. Instead of expecting that, our generic
filter harness module should abstract the protocol and deal with
these headers on behalf of modules.
We can identify three output filter cases:
- No change to the content.
- Byte values change but length is preserved. Headers such as
Content-MD5 are invalidated, but others like Content-Length are
preserved.
- Arbitrary content transformation. Several headers are affected.
For HTTP/1.1 requests, we should ensure the response is chunked (unless
force-response-1.0 is in effect).
A second distinction concerns whether cacheability is affected
by a filter. There may be more than one way to deal with this, as
demonstrated by the different uses of XBitHack with SSI. We should
abstract the cacheing behaviour affecting Last-Modified and Cache-Control
headers.
Request headers may also be affected.
