You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2003/06/20 12:56:46 UTC

DO NOT REPLY [Bug 20946] New: - mod_ext_filter vs mod_include

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20946>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20946

mod_ext_filter vs mod_include

           Summary: mod_ext_filter vs mod_include
           Product: Apache httpd-2.0
           Version: 2.0.46
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: mod_ext_filter
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: apache@neil.fraser.name


Currently if server-side includes are active, and mod_ext_filter is active,
mod_ext_filter goes first, then mod_include goes second.  There doesn't appear
to be any way of reversing this order in the configuration.

I would argue that either the order should be configurable, or if not, the order
should be reversed.  Arguments for this are:
* mod_ext_filter is a slow application, thus it should be called once on the
final output, rather than many times for components.
* A filter that just gets SSI fragments is unable to know the context of the
fragment (is it in the body, in the head, in a textarea, etc).  This means
filters can't formatting, many types of logging, or other useful tasks.
* If the order were reversed, bug 20945 would vanish.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org