httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Broken SetOutputFilter/SetInputFilter semantics
Date Wed, 29 Aug 2001 18:48:44 GMT
Folks,

  I'm working on the AddOutputFilterByType/AddInputFilterByType patch to core.c.
I'll drop it into core.c, since we only have three other ByType directives (AddIcon
and AddDesc from mod_autoindex, and ExpiresByType in mod_expires.)

  I discovered something's pecular about SetOutputFilter/SetInputFilter.  Unlike every
similar SetFoo directive, we keep stacking them on, and have no remove function.
Warning; I'm discussing _only_ content filters here, connection and parent request 
filters aren't even considered!!!

----

  Essentially, a user trying a SetFoo function expects it to override any SetFoo
in a parent resource (.htaccess over <Location>, <Location> over <Files>,
<Files>
over <Dir> and <Dir> over <VHost>.)

  Right now we add 'just one more'.  But we can't take them out.  This is borked.

  In the mod_mime patch I tossed in yesterday, each recognized extension can add filters 
(in the order the extensions occur in the filename, L2R order.)  But I added the 
corresponding RemoveInputFilter/RemoveOutputFilter the filename association in a nested 
container.  And each AddInputFilter directive _replaces_ the previous AddInputFilter 
directive for that same extention.

----

  Note that SetHandler shares part of this problem, it can't be overriden in a nested 
container.  This is wrong, so consider that UnSetHandler (no arg) will undo that problem.
Therefore SetFooFilter filters gets an UnSetFooFilters (no arg), and either can be undone
in a child container.  That's part of the problem, so onwards...

----

  That means that RemoveFooFilter BogusFilter .bak will take any filters away from the
.bak extension that were defined before for the .bak extension.  That does NOT mean 
that .bak will cause other extensions to be removed, so foo.shtml.bak would KEEP it's 
Includes filter.  That is how Add|Remove mod_mime things work.

  For mod_mime's semantics, the syntax is AddFooFilter filters ext [ext...].  We could not

use the semantic AddFooFilters filter [filter...] ext since it's ambigious. Instead I used

semicolons to allow multiple filters for the same extension, so an shtml-gz *could* be
defined to run through GUnZip;Includes (not that I see many doing this.  It will be an
obscure, rarely used but useful feature.)

  So now we have a ton of extensions adding filters, will soon have AddFooFilterByType
adding filters, and finally SetFooFilter adding more at the end.  Handlers were never
this difficult to configure :(

  I'm suggesting, today, that we support the following syntax for all these directives;

{Add|Remove}{Input|Output}Filter [+|-]foo[;[+|-]bar...] ext [ext...]

{Add|Remove}{Input|Output}FilterByType [+|-]foo[;[+|-]bar...] [mime-type]

Set{Input|Output}Filter [+|-]foo[;[+|-]bar...]   OR  UnSet{Input|Output}Filter

  Again, UnSetFooFilter takes no args, it undoes the SetFilter, that's all.  It has no 
effect on the Add/RemoveFooFilter stuff.  Apache will get an UnSetHandler that does the
very same thing.

---

  These filters would be run in the order above.  An absolute syntax in any of the above
will CLEAR the content filter list.  Any of these directives will OVERRIDE the prior
definition of the same directive.  So in this example;

AddOutputFilter +charset .utf-8

AddOutputFilter +includes .shtml

<Directory />
    SetOutputFilter none
</Directory>

<Directory /webroot>
    SetOutputFilter +decoration
<Directory>

<Directory /webroot/someweb>
    UnSetOutputFilter
<Directory>

  If we ask for the file /something/test.utf-8.shtml, mod_mime hits utf-8, which adds the

charset filter, we hit .shtml, which adds includes, and then the core filter clears them
all.

  If we ask for the file /webroot/test.utf-8.shtml, when the core filter merged the
<Dir> blocks it started with none, then changed it's mind to +decoration.  So mod_mime
hits 
utf-8, which adds the charset filter, then .shtml, which adds includes and the core filter

adds the decoration filter.

  If we ask for the file /webroot/someweb/test.shtml, mod_mime adds includes, and then
the core filter (after merging the <Directory > blocks) doesn't change a thing.

----

  I'm suggesting ALL of these filters run in the mime negotation and fixups phase.  That
way, any module that uses the insert_filters hook will ALWAYS override these user configured
filters, so that modules will rarely be broken by user configuration errors.  Here are the
phases I suggest;

mime_types hook  :::  Add[foo]OutputFilter is run in mod_mime's hook

fixups hook      :::  Add[foo]OutputFilterByType is run in the core's hook

insert_hooks     :::  SetHandler (absolute) is run in the core's hook

----

  If we don't get this right, httpd-2.0 will be resoundingly booed by the Administrator
community a year from now.  Please - help me out with your comments ;)

Bill




Mime
View raw message