httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tony Finch <>
Subject Re: AddOutputFilter hook needed?
Date Tue, 19 Sep 2000 21:47:01 GMT
Jeff Trawick <> wrote:
>chunk_filter is request-oriented in that it acts on the
>request/response bodies (content) and respects request boundaries and
>doesn't touch header fields.  It is set up on a request-by-request
>basis depending on info from the connection (protocol level) and info
>from the request/response (content-length?)  It seems more of a
>content filter than a connection filter.

Correct, since it corresponds to the Transfer-Encoding header. There
should be an ordering of filters corresponding to the HTTP headers
Content-Type, Content-Encoding, and Transfer-Encoding.
(Content-Language might also fit in there between Content-Type and
Content-Encoding, if we had a mod_babelfish.) In fact, the RFC says:

> 7.2.1 Type
>    When an entity-body is included with a message, the data type of that
>    body is determined via the header fields Content-Type and Content-
>    Encoding. These define a two-layer, ordered encoding model:
>        entity-body := Content-Encoding( Content-Type( data ) )

Transfer-Encoding isn't included in the same framework in the RFC
although that would work perfectly well. That's perhaps because MIME
uses Content-Transfer-Encoding instead.

Whether the server should enforce the ordering of filters is still
unclear, at least to me. The alternative is to just hope that they end
up in the right place because of when and why they get inserted. You
could go further in the strict direction and have the server check
that the output data type (all the headers mentioned earlier) of one
filter is compatible with the input data type of the next one.

>Perhaps calling it a connection filter and adding it in a certain
>order with respect to core_filter makes it work with the current
>ap_add_filter() implementation?


>core_filter is connection-oriented, of course.

In fact it's the only filter that isn't per-request. The
implementation charset filter doesn't particularly care about
different requests, but it needs to respect EOS buckets to make sure
data doesn't hang around in the server when it should go to the

en oeccget g mtcaa    f.a.n.finch
v spdlkishrhtewe y
eatp o v eiti i d.

View raw message