httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: recap of filtered I/O
Date Mon, 05 Jun 2000 06:20:56 GMT
In a message dated 00-06-05 02:11:33 EDT, you write:

> > I guess the way I see it is that during the post_read_request phase the
>  > modules register which filters/layers to use (along with the filter
>  In both schemes, we plan to introduce a "install_filters" hook that runs
>  just before the "handler" phase. This hook allows the modules to examine
>  the request/response and base a filter-insertion on the values
>  found.

I hope that's a firm plan. The filtering scheme(s) won't be much
good without it.


There should also be a way to quickly 'know' about what has already
happened in other filtering schemes without having to walk the
chain each time to see 'where you are'. Something similar to the
way the 'Via:' field works which is a fast way to trace who/what
has touched a request/response before you.

And dont' forget that some filtering schemes will always need
access to both original header values AND be able to see the
'changed' header values ( if any ) while the filtering chain is walked.

If a filter CHANGES any of the request/response headers while
'doing it's thing' ( Example: Dynamic content encoding will ADD
the 'Content-encoding: whatever' header but it will also CHANGE
the 'Content-length:' header ) then those 'changes' should be
visible to other layers without original values simply being
willy-nilly 'replaced' leaving each succeeding layer to wonder
what the original header(s) looked like.

Perhaps the context should actually have a 'linked list' of
header values as they pass from filter to filter so that any
one 'layer' can 'see' the changes made in the order they
were made.

Another example: A 'filter' that is designed to scale graphics
images for a mobile user-agent will 'see' the User-Agent
field and the mime type and know if it's a GIF or JPEG, but
unless it knows what has already transpired with that image
data ( it might already have been compressed by another
filter ) then it might do the wrong thing at that point.

View raw message