Open source support really works
One of the early arguments against Linux and other open source solutions was lack of support. People "in the know" have always known that the better projects (Apache, Linux, FreeBSD, MySQL, to name a few) provide amazing and transparent support via extensive documentation, mailing lists, and public bug databases. Just recently, we here at InfoWorld benefited first-hand from the beauty of open source development, specifically Apache. Kevin Varley, one of our developers, discovered a bug in Apache and it was promptly dealt with by the Apache team, with a detailed (and friendly) explanation of the bug and a patch to fix it (see the bug report). I already knew the open source support system worked, but it was nice to see it up closer than I usually do.
Here's what happened. We're using Apache 2.0 for infoworld.com, having upgraded from 1.3 back in January of this year. We needed to do some basic dynamic page generation for our redesign, and we decided that the simplest way to fulfill this need would be to use conditional server-side includes -- running an app server with JSP or even PHP would have been overkill in this case. I've used pretty much all permutations of server-side includes in the past, except for conditional SSIs, but since the documentation for this capability hadn't changed since Apache 1.3, I figured it was safe. Unfortunately, seemingly random problems with SSI processing seemed to occur. As Kevin noted in his bug report:
Initially, we noticed that, on certain pages on our site, SSI directives would
stop being processed about halfway through the page. I began looking into the
problem by checking our syntax, looking for any wierd characters in a hex
editor and then finally by making small changes to the file to see if it
affected the service of the page. The first oddity that I came across was
that if I opened up the problematic file and inserted a single space at the
beginning, the SSI directives would all be correctly processed. If I again
removed the space, the problem came back..about halfway down the page, after a
block of SSI conditionals, the rest of the SSIs were not processed and the SSI
tags were sent to the browser. After a little more investigation, I noticed
that the problem seemed to always manifest itself when the last character of
an SSI conditional block (e.g. the final > in <!--#endif-->) occurred at the
8000th byte in the file . To test this out, I created a completely new test
file, ensuring that the final character in a conditional SSI block was the
8000th byte and I placed another include immediately after the conditional
block. Sure enough, the directives in the conditional block were processed
successfully but the include after the conditionals was sent to the browser.
I then tested this same issue out using a virtual include directive instead of
a conditional block and the result was the same.
Ultimately, we learned from the Apache team that the bug was confined to Apache 2.0 servers that are configured with "EnableMMAP off," which is recommended if your Apache server uses an NFS volume (such as a Network Appliance, which we are using) as its DocumentRoot. Fairly obscure stuff, but important to us.
Considering that the Apache project is driven completely by volunteers, I'm really impressed with the initial response to the bug on June 29 (Andre Malo -- in the photo here -- wrote from Germany: "Thanks for your detailed description! Will dig into the code.") and the ultimate follow-through when a patch was delivered by Cliff Woolley (from Virginia) on July 11. Thom May also chimed in from London. This is truly great global support and a small but illustrative example of the power of open source collaboration.
If you're running the Apache web server (or any of the other projects supported by the Apache Software Foundation), you should really contribute. My C skills would be a burden to the Apache Software Foundation, so I'm sending them a check today. A big thanks to Andre, Cliff, and the rest of the Apache web server team!
Posted by Chad Dickerson at
03:29 PM