mod_include/6164: "echo var"'s new default of encoding the output severly and needlessly breaks compatiblity

[Byron Brummer <by...@omix.com>]

>Number:         6164
>Category:       mod_include
>Synopsis:       "echo var"'s new default of encoding the output severly and needlessly breaks compatiblity
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    apache
>State:          open
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Thu Jun 08 12:00:00 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     byron@omix.com
>Release:        1.3.12
>Organization:
apache
>Environment:
All OS, all patch levels, all compilers.  Eg, this is a mis-feature/code bug,
not a platform bug.
>Description:
>From CHANGES:

  *) mod_include now entity encodes output from "printenv" and "echo var"
     by default.  The encoding for "echo var" can be set to URL encoding
     or no encoding using the new "encoding" attribute to the echo tag.
     [Marc Slemko]

This is simply not acceptible.  We use echo var at times to dynamically inject
small pieces of HTML code.  We've done this for years, and works quite well.  This
new "feature" breaks this entirely, requiring every page that uses echo var to
be manually changed to include "encoding=none", which of course doesn't work
on older Apache versions at all, let alone across SSI implementations of other
servers.

There is no justification for this change.  At the very least, there should exist
an httpd.conf directive to change this default globally or per directory/location.

At this point, we can not use 1.3.12 without manually pulling this change out of
mod_include.c as this affects thousands of pages, some which span differing
web server venders.
>How-To-Repeat:

>Fix:

The encoding options are a nice idea, implemented carelessly.  The following
recommendations are thus made:

1) Return the default encoding to "none".
2) Add an httpd.conf directive to change the default encoding, perhaps even
   offer a method to extend it, but again defaulting to "none".
3) In the future, think about compatiblity before blindly implementing the new
   wis-bang feature of the week.

Thank you.

-Byron Brummer, a highly disgruntled Apache user.
>Release-Note:
>Audit-Trail:
>Unformatted:
 [In order for any reply to be added to the PR database, you need]
 [to include <ap...@Apache.Org> in the Cc line and make sure the]
 [subject line starts with the report component and number, with ]
 [or without any 'Re:' prefixes (such as "general/1098:" or      ]
 ["Re: general/1098:").  If the subject doesn't match this       ]
 [pattern, your message will be misfiled and ignored.  The       ]
 ["apbugs" address is not added to the Cc line of messages from  ]
 [the database automatically because of the potential for mail   ]
 [loops.  If you do not include this Cc, your reply may be ig-   ]
 [nored unless you are responding to an explicit request from a  ]
 [developer.  Reply only with text; DO NOT SEND ATTACHMENTS!     ]