UPDATE 2023-03-27: This page is obsolete, as it refers to a prior version of this blog. However, it may be of historical interest.
When stock Blosxom sees a URL that doesn’t correspond to an existing entry or list of entries, it simply puts up a “normal” page (i.e., using the standard heat and foot templates for that flavour) that doesn’t have any actual content. I really don’t like this behavior, and thus I decided to try out the emptymessage plugin created by Fletcher Penney. Unfortunately I wasn’t entirely happy with its behavior either, and so I decided to patch it.
First, I didn’t like the standard “404 Not Found” message produced by the plugin; it was reminiscent of the standard message produced by Apache, but different enough that it got on my nerves. My first patch was therefore to make the 404 message produced by the emptymessage plugin look exactly like the standard message produced by Apache 2.0, even down to including the same information about the server version, etc. (You can compare for yourself by trying a bogus URL for my blog vs. another bogus URL for a static site hosted on the same system.)
My second patch wasn’t to fix an actual problem but rather to make the emptymessage plugin work better with another plugin I’m creating that also wants to set the HTTP Status header in the response. In the original emptymessage code the HTTP status is set by doing an actual print operation to output the Status header; unfortunately doing it this way means that other plugins have no way of detecting that the status was thus set, in case they want to modify their own behavior.
To address this problem I patched the emptymessage plugin to set the status header using $blosxom::header->{'Status'}; other plugins can then check that variable to determine what the HTTP status will be. At the same time I also changed the emptymessage plugin to produce a Content-length header (by setting $blosxom::header->{'Content-length'}) for further compatibility with Apache.
The above patches worked fine in testing (which I do using a stand-alone Apache server located on my laptop) but when I deployed the emptymessage plugin to my production site it didn’t seem to be working at all: The returned response for an empty/non-existent page was exactly the same as if the plugin were not installed.
After doing some debugging I discovered the problem: The data directory on my production site has a period in the pathname (e.g., /usr/local/foo.bar) and the emptymessage plugin was mangling the pathname in its attempts to take the Blosxom $currentdir variable, prepend the data directory pathname, and then strip off any flavour suffix (i.e., after a ’.’). I patched this by changing the order of operations so that the flavour suffix was stripped before prepending the data directory.
For more details on the above changes see the patch itself.
A final note: The emptymessage plugin still doesn’t address one important case, namely when a request is made for a date-based archive page (e.g., http://www.example.com/blog/2005/01) and there are no entries for that date. I may look at providing a patch for that later.