mod_annot editor

Annotate Section

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.