Legal encumbrance

From Ubersoft.  "The statistical probability ..."

( Cut for your friends page's pleasure )

Also see Ayn Rand, I believe.

Reading between the lines ...

... sounds like a Keyhole is coming down.

Fixed! But it shouldn't have had to be this hard.

As I alluded to previously, I've had the devil's own time getting everything working after upgrading to Apache 2.2.8.  I eventually gave up on getting suexec working, since Apache 2.2 seemed to be in persistent denial about the existence of the suexec binary and I could get all of the functionality of the DSPAM CGI interface that I needed working without running it in a suexec environment.  (I think I can do everything except update preferences, and user prefs are pretty stable by this time.)  I also got mailgraph working after upgrading it, with only a few minor code tweaks.  That just left my custom CGI ErrorDocuments to solve.

With the aid of a fresh pair of eyes on the problem from rbos, who asked a question I hadn't thought to ask, it's finally solved.  The mystery was that if I set up a ScriptAlias to load the CGI directly, it worked, but it failed if invoked as an ErrorDocument.

As noted in the SciptAlias documentation, "It is safer to avoid placing CGI scripts under the DocumentRoot in order to avoid accidentally revealing their source code if the configuration is ever changed. The ScriptAlias makes this easy by mapping a URL and designating CGI scripts at the same time."  And indeed, I keep my CGI directories outside my DocumentRoot.  Including, reasonably enough on the face of it, my custom ErrorDocument CGIs.  And therein lies the secret behind the problem.

You see, when processing a redirect specified by an ErrorDocument directive, Apache 2.x does not resolve ScriptAliases.  Apache 1.x did.  So if you have an ErrorDocument like, say, /cgi-bin/404.cgi, and /cgi-bin is a ScriptAlias to a directory outside your DocumentRoot, and you're running Apache 1.x, Apache will resolve the ScriptAlias, find the CGI in the correct place, use it, just like any other CGI, and it'll work fine.  Load that same CGI manually from Apache 2.x in a browser, and again, it'll work.  But when calling it as an ErrorDocument, Apache 2.x will NOT resolve the ScriptAlias, will try to use DocumentRoot/cgi-bin/404.cgi instead, find it missing, and throw a 500 Internal Server Error.  Then it won't tell you anything about what caused the error.

Worse, this isn't documented, so there was no reason to believe that what worked on Apache 1.x wouldn't continue to work on Apache 2.x.

This violates at least two principles of good software design:  the Principle of Least Astonishment, and the mantra that Silent Failures Are Bad.

Update:

Well, bugger.  The one thing I need done that dspam.cgi cannot do while running as mosaic instead of as dspam is redeliver false positives.  That's a major problem.