httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [PATCH] ap_add_filter
Date Thu, 17 Aug 2000 15:06:09 GMT

In a message dated 00-08-17 14:16:42 EDT, Roy Fielding writes...

> >In other words... only filters of a certain TYPE can 'insert'
> >filters of the SAME TYPE immediately after themselves
> >or your stack might get messed up. I don't see any filter
> >type checking in the patch.
>  That would be wrong.  The only difference between a transfer coding
>  filter for deflate and a content coding filter for deflate is when
>  and where in the chain the filter is inserted. 

And when and where in the chain someone touches the headers
to indicate the difference. Both require a check on 'Accept encoding:'
and 'User-Agent:' field and both make different changes/additions
to the output headers.

CE a 'content filter' and TE is a 'transport' filter.

That amounts to different TYPES as far as the current design
is concerned, yes?

>  for the server to be misconfigured, causing filters to be inserted in
>  the wrong order: the result will be garbage.  We don't need to
>  prevent people from implementing garbage.
>  ....Roy

This seems to imply the opposite of what you said yesterday
with regards to WHEN the ordering of filters takes place. The
comment above seems to imply that all of that is taken care
during startup when modules load but yesterday you pointed out 
how important it was to take care of it during run-time...

Is it not the issue about what a filter itself can or can't do 
dynamically that we are sorting out here? What if a filter
needs to insert/delete other special kinds of filters solely
based on the header values of the current transaction?

Example: A multi-algorithm compression filter won't know what kind of
compression sub-filter needs to be installed until it looks at
the 'Accept-Encoding' field of each and every transaction.

> In a previous message... Roy Fielding wrote...
> At least that's the way I imagined it working.  In all of this, the only
> reason to differentiate between types of filters is to make it more
> efficient to register filters by encoding name or purpose.  Ordering of
> the filters must be directly controlled at run-time, which is why the
> table-based hook sorting stuff is simply not going to work for filters.
> Roy Fielding 

"Ordering of the filters must be directly controlled at run-time".

Yes... but doesn't that ordering STILL depend on 'type'?

All of the CONTENT filters must be grouped together in
the right order and all of the TRANSPORT filters must 
be grouped together as well, yes?

If 'ap_add_filter()' is going to allow an insertion but not make
sure a CONTENT filter doesn't try to add a TRANSPORT
filter in the wrong place of vice-versa... then who does that? 
I don't see the policeman for that anywhere in the patches.

Kevin Kiley
CTO, Remote Communications, Inc. - Online Internet Content Compression Server

View raw message