Jorey Bump wrote .. > Graham Dumpleton wrote: > > Anyone know if there are any technical reasons why input/output filters > > as they exist at the moment, applying only to body content and not > > headers, can not be specified in a .htaccess files? > > > > ... > > > > So, does anyone know why this might be a bad idea? I can't really think of > > any reasons why it shouldn't be okay. If there is some confirmation that > > it all sounds reasonable, I'll create a JIRA issue for it to be a future > > enhancement. > > Are there any conflicts when a directive appears in both places? If not, > how do they cascade (does the .htaccess trump the one in the conf file, > is it additive, does it respect virtual host or directory boundaries, > etc...)?
It seems to behave as directives would normally behave. That is, a directive which sets a value will see that which is more specific, ie., defined in a .htaccess file, override one set in the server configuration. Thus: # server configuration PythonOutputFilter uppercase UPPERCASE SetOutputFilter UPPERCASE # .htaccess PythonOutputFilter lowercase LOWERCASE SetOutputFilter LOWERCASE Output will be sent through Python lowercase::outputfilter() only. With filters actually being an indirect name, late binding will occur. # server configuration (deliberate mistake follows) PythonOutputFilter lowercase UPPERCASE SetOutputFilter UPPERCASE # .htaccess PythonOutputFilter uppercase UPPERCASE Output will be sent through Python uppercase::outputfilter() only. Ie., naming of filter in .htaccess file takes precedence even though relationships initially created in server configuration file. In a .htaccess file, you could chain filters defined in different contexts. SetOutputFilter LOWERCASE;UPPERCASE Same sort of thing when AddOutputFilter is used. Graham
