Moving my personal website to Hugo. I’d been increasingly frustrated with using Jekyll to manage my frankhecker.com website. I went looking for another static site generator, decided Hugo was the best choice for what I wanted to do, and spent a couple of weeks a year ago converting my old site to work with Hugo. I also made several other improvements, outlined in the blog post “New year, new blog.” I hope this will be the last re-architecture of the site I will want or need to make. (Although I don’t rule out updating the blog theme, especially if I could find a suitable person I could pay to do the work.)

Coping with the end of Cohost. Ironically enough, after I revamped my personal website I did no writing at all specifically for the site. Instead I devoted my attention to the Cohost social media site and did all my writing there, for reasons I’ve previously explained. All told, the almost two years I spent writing on Cohost for my followers, and reading what others had to say, were the most fun and rewarding I’ve ever experienced in my life online.

Unfortunately, all good things must come to an end sooner or later. For Cohost it was sooner, as financial reality caught up with its staff and owners, the site went read-only on October 1, 2024, and it will shut down completely sometime soon.

Fortunately Cohost staff provided an export mechanism, and I’ve recreated almost all of my Cohost posts on this site, dated to the date I originally published them. (The major exception is my “Sunday night poetry” series, for which see below.) As an extra precaution I’ve requested that the Internet Archive save a final copy of all my Cohost posts in the Wayback Machine, and I’ve updated Cohost-related posts on this site to point to the archived copies.

Writing at Okazu. I’ve been reading Erica Friedman’s Okazu blog and associated Yuricon website, ever since I got interested in yuri manga, and have been a site supporter and participant in the Okazu discord for a few years now. After the debut of GAP: The Series I also got interested in Thai yuri (aka GL) live-action shows, wrote a couple of reviews for Okazu as a guest reviewer, and then had the honor of being named a staff writer at the beginning of June 2024, with my self-chosen “beat” being live-action series from Southeast and East Asia.

What about the new year? 2025 will likely see one or two major changes in my life, but I’m not ready to talk about them yet. My main commitment is to recreate my “Sunday night poetry” series here, with some added poets and poems. I’ll also continue reviewing for Okazu, and plan to take some of my Bluesky comments and turn them into blog posts when and where that makes sense.

Beyond that, things are up in the air. I definitely plan to do some learning, but I’m not ready to publicly commit to what yet. In the meantime, Happy New Year to all of you who stumble on this post! You have my best wishes for a joyful and successful 2025.

(I was going to publish this soon after New Years Day–hence the title–but never got around to it. But better late than never, so here it is. I couldn’t think of a better title.)

I’ve maintained a personal domain and associated website since the turn of the century. Every once in a while I get the urge to revamp it in ways large or small. This is the latest version, created using the Hugo static site generator working from source files in Markdown format. I switched to Hugo from Jekyll, used for the previous version of the site. Besides being considerably faster to generate the site and considerably simpler to install and maintain, Hugo also allowed me to re-use a different style of URLs from a previous site organization, which (fingers crossed) should allow old links to once again work.

Like an ancient city periodically rebuilt over the ruins of an older one, previous versions of this site are still visible here and there. The site has had the following forms over the years:

• 2000: I created my first personal website, hand-coded in HTML and published at the domain name www.hecker.org. (I hosted it on a Dell server running what later became Red Hat Enterprise Linux; a coworker of mine had bought the server for his own websites, and let me host my own stuff on the server in exchange for administering it.) The “interests” page is a mostly-unmodified page from that site, and a good guide to what I was reading and listening to back then.
• 2004: I adopted the Blosxom blogging software and did quite a bit of work to make the site as standards compliant as possible (and in the process learned a great deal about how the HTTP protocol works). You can find a number of in-depth posts about that work using the “blosxom” tag.
• 2006: I started a separate blog Swindleeeee!!!!! on Wordpress.com to discuss the eMusic service. I later folded that blog back into my main blog; see the “eMusic” tag for those posts.
• 2008: I moved my main blog to Wordpress.com as blog.hecker.org. (I continued to host the hecker.org website on the same server as before, so that older posts remained available.)
• 2011: I changed the blog’s name to frankhecker.com.
• 2015: I moved off Wordpress.com and created a new blog civilityandtruth.com using the Jekyll static site generator.
• 2019: I started a separate Substack newsletter, also named Civility and Truth.
• 2021: I closed down the Substack newsletter and renamed my blog back to frankhecker.com, still using Jekyll to generate it.
• 2024: I converted all Markdown posts to the format used by Hugo, corrected typos and missing images where I found them, fixed the quotation marks in posts that had been stripped of them (an unfortunate side effect of moving off Wordpress way back when), re-added comments submitted to the old Blosxom and Wordpress versions of the blog, and re-incorporated old pages that had been left behind in the various blog migrations. I also generated a web version of my book That Type of Girl.

My goal for this version of the blog is to serve as a permanent record of my writing, in a form that is relatively low maintenance and should be readable for many years to come. Except for the occasional post I no longer write directly for the site; almost all my current writing is done on the Cohost site, where people can comment on it and share it with others. As time goes on I’ll bring some Cohost posts over here (after slight revisions); if Cohost threatens to go under (a real possibility) I’ll accelerate that process.

After a fair amount of fiddling about I’m renaming my personal blog and moving to a new domain. From now on you can access the blog at https://civilityandtruth.com (note the “https” rather than “http”).

You can read more about the changes in my first post at the new blog. Briefly, I wanted to separate the blog from my personal domain frankhecker.com and have more control over the technology behind the blog, including eliminating the user tracking done by WordPress.com and providing better support for posts that include programming code and mathematical notation.

I have moved all of my old blog posts from frankhecker.com to civilityandtruth.com, although some of the older ones have minor formatting glitches I have yet to correct. For now you can access old posts at the frankhecker.com URLs, but sometime in October (once I finish fixing any formatting problems) I will have all URLs pointing to frankhecker.com posts automatically redirected to the posts on civilityandtruth.com. The bottom line is that if you have linked to any of my old frankhecker.com posts those links should continue to work both now and in the future.

However if you use news reader software (e.g., NetNewsWire) or a news reader service (e.g., Feedly) to read my blog posts then you should reconfigure your software or service to use https://civilityandtruth.com/feed.xml as the feed URL for the blog. I may be able to redirect previous feed URLs, but I cannot guarantee this will work in all cases.

Finally, an important note: The new blog does not support comments (for a number of reasons); instead I’m expecting people to comment on Facebook or Twitter, or just to send me email. If you really don’t like this and would much prefer to comment directly on blog posts, drop me a line (or post a comment below) and I’ll consider changing my decision.

Thanks to all of you who have read my blog over the years; see you at civilityandtruth.com!

Update 2021/06/19: I decided to go back to using my personal domain frankhecker.com as the main domain for my blog. However links to civilityandtruth.com should still work, and will be redirected to frankhecker.com.

It’s been almost four months since I last posted something on my blog. I’m sure at least one or two of my few long-time readers have been wondering if I was ever going to post again. Fear not, the hiatus is officially over!

Most of that time was taken by my generally goofing off (not having any real motivation to write). However a good part of it I spent reworking the blog. Today is the official relaunch.

What’s changed? First is the name. I’ve always felt it was somewhat lame to use my own name as the name for my blog, but I couldn’t think of a good alternative. “Civility and truth” was part of the tagline for my old blog, and I finally decided to promote it to be the actual name of the blog itself. See the “about this blog” page for the story behind the new name.

With the name change comes a change to the URL: The blog is now officially accessible at https://civilityandtruth.com (note the “https” at the front). If you are using a news reader service (e.g., Feedly or NewsBlur) then you should add the Civility and Truth news feed using the URL https://civilityandtruth.com/feed.xml (an Atom format feed, in case you’re curious).

If you have previously linked to my old blog at frankhecker.com, never fear: Sometime in the next month or so I will reconfigure my old blog so that all links to old blog posts get automatically redirected to the corresponding posts at Civility and Truth. At that time I’ll convert the frankhecker.com site to be a simple landing page linking to my various blogs and social media presences.

One major change is in the appearance of the site and the technology behind it. I’ll spare you all the technical details (see the “about this blog” page for that), but the result is that the site should load faster and look nicer on smartphones and tablets, you should never see an advertisement or other intrusive third-party content, and (as much as I can arrange) your browsing activity on the blog will not be tracked and monetized by third parties.¹

A final and potentially controversial change is that I decided to not provide a way to post comments directly to the blog. I thought long and hard about this: I personally like commenting on blogs, but I got very few comments on my own blog, and many of those were spam that I had to delete. Providing my own commenting system on a self-hosted blog would be far from trivial in terms of dealing with spam and other security issues, and I’d rather not use a third-party service like Disqus whose revenue model depends at least in part on user tracking.

For now I’ve decided to direct people to post comments on Facebook or Twitter (where I will post notices of new blog posts) or to email them directly to me. If I get particularly interesting and worthwhile comments through these channels I may update blog posts to summarize and quote from such comments. If you’d really really rather be able to comment directly then please let me know and I will consider adding Disqus commenting with an opt-out for user tracking.

What hasn’t changed? I will continue to focus on issues relevant to Howard County and Maryland, with an emphasis on in-depth analysis and minimal snarkiness and partisanship.² I’ll continue to supplement Howard-centric posts with more general commentary on public affairs, combined with whatever else strikes my fancy.

I’ve learned through bitter experience that I am not a daily blogger, or even necessarily a weekly one. My goal going forward is to post a new item at least once every two weeks, typically on Saturday morning for your weekend reading pleasure. Thanks to all of you who’ve read my blog over the past few years; I hope you enjoy this new incarnation of it!

A little history by way of background: I was around when the Internet was first being commercialized, and I had the opportunity to register hecker.com for myself if I really wanted to. However I passed because I didn’t have a server to associate with it and I thought I needed to be running an actual server in order to register the name (though I’m not sure that was the case even then). When I finally got around to having a personal server in the late 1990s I found that hecker.com had already been taken by a company that registered thousands of surname domains so that they could offer a shared domain service in which multiple people could have their own personal subdomains under a top-level domain: jane.smith.com, john.smith.com, and so on. So I settled on the next best thing and registered hecker.org instead for use as my primary domain, at the same time registering frankhecker.com (as well as the .org and .net variants) to prevent anyone else from getting it.

When I first started a blog I hosted it at hecker.org using custom blogging software. I later got tired of the management hassles involved, and moved my blog to WordPress.com, using the subdomain blog.hecker.org because I was still hosting other things at hecker.org and couldn’t afford to dedicate the entire domain just to my blog. Since then though the blog has assumed more importance as my public face to the world, and I regretted having a somewhat unusual domain name for it. I’ve therefore decided to adopt the conventional approach and use frankhecker.com as my primary blog name. (As noted above the old name of blog.hecker.org will continue to work, thanks to the magic of HTTP redirects.)

Note that my primary personal email address remains hecker@hecker.org; I have no plans to change that. However I can also receive email at frankhecker.com, so for example sending email to frank@frankhecker.com will get to the same inbox as hecker@hecker.org. I may switch over completely to frankhecker.com for all uses in future, but in the meantime there’s no need to update your address book.

In other news, I’m now on Google Plus so you can add me to one of your circles if you’d like. I’ve been meaning to try Google Plus out before now, but I use Google Apps for my email and related services, and Google Plus wasn’t added to Google Apps until this week. I’ll publish notices of new blog posts to Google Plus, and maybe some other stuff from time to time.

After much struggle I’ve finally managed to get my blog to support comments and TrackBacks. (This is what I get for using “roll your own” blogging software.) I’ll blog some more later about how I did this, for any Blosxom users who happen to be interested; in the meantime please report any problems to me, either as comments on this post (if you’re able to) or via email.

UPDATE: I now have a blog post describing the new Blosxom plugin I wrote to support comments and TrackBacks.

After a long period of neglecting my personal web site, I’ve decided to start my own weblog, with the goal of making it easier for me to publish new material and therefore (I hope) more likely that I’ll actually write more.

My plan is to write about things that interest me, on the theory that they might interest at least a few other people. As part of that I’ll occasionally discuss the volunteer work I’ve been doing for the Mozilla project.

While this site has been up and running for several weeks, today marks what I consider to be its official launch. The site design is frozen, at least for now, and I now have all the site features in place that I wanted to have, at least for an initial attempt. The major missing piece is a comments system; I’ve delayed doing this until or unless I can put some reasonable measures in place against comment spam.

After this date I won’t introduce changes to the site without careful testing, in an effort not to break things. I also won’t arbitrarily change the dates on entries, in order to avoid problems with news aggregators.

As many people can attest, sometimes you spend more time (and have more fun) tinkering with the underpinnings of a web site instead of actually writing new content to be posted on it. In that spirit, here is my current list of things I’m planning to add to or change about my web site and blog.

(I’ve left old items in place but simply marked them as deleted.)

The following are “must-haves”:

• blog overlays old site (working)
  • URI rewriting for cononical URIs (done)
  • don’t special case POST for now (but may need to later?)
• extensionless URIs (working)
  • plugin for Blosxom (done)
  • load as 20extensionless? (after content negotiation, before everything else) (done, loaded as first extension)
  • fix breadcrumbs, check for issues wtth other plugins (seemore, etc. ) (no seemore patch needed, need to post patch to breadcrumbs)
  • MultiViews for Apache (decided not to do this, but instead special-case .html in URI rewriting, will use .var files if I ever need more than that)
  • check for cruft (e.g., *.bak) (done, site can now be regenerated from scratch and be cleaned up with make remote-clean)
• XHTML version (postponed)
  • return .xhtml vs .html based on Accept header? (decided against this, as it would require special-casing Internet Explorer)
• basic feed (working)
  • vanilla RSS 0.91 (done)
  • validate feed (feedvalidator.org) (done)
  • try to “stupefy” excerpts to remove fancy punctuation? strip HTML? (left as is for now)
  • fix problem with example HTML tags messing up in NewsFire
• site and category intros
  • use readme plugin (done)
  • add readme content to feed as description?
• HTML 4.01 Strict
  • create HTML 4.01 Strict flavour files (done)
  • patch Markdown to generate HTML-compliant empty tags (done)
  • put validation check in footer (done)
  • validate all visible pages
  • fix old pages
• CSS
  • simplify CSS more if possible
  • change old pages to new design (in progress)
  • add print media style (done)
  • eliminate common.css? (may keep this for Netscape Navigator 4.x)
  • determine proper invocation (done, use @import to hide from Netscape Navigator 4.x)
• accessibility
  • do Bobby, etc., checks
  • get tips from diveintomark (done)
  • accessibility statement (have draft)
• typography/markup
  • tweak SmartyPants as necessary (not needed?)
  • add needed entities to template files (including RSS? ), readme files
• dating posts (working)
  • put date stamp in entry file (done)
  • compare entries_cache_meta plugin to meta plugin plus something else (done, using entries_cache_meta)
  • handle dates for statically-generated pages (have initial hack)
• decide on archive (done, using the archives plugin)
• nail down site hierarchy (see below)
• other
  • look at bettertitles? (done, using bettertitles)
  • change Blosxom file extension from .txt to something else (e.g., .bls) (leaving as-is for now)
  • finalize plugin list and establish an order for them to run (done, using SEQUENCE file to generate prefixes on the fly when copying over new or modified plugins)
  • fix readme invocation (add P tag to readme.html? ) (no, this causes problems in practice, use one-paragraph readme blurbs)

The following are desirable but not necessarily “must-have”:

• search
  • using Google SiteSearch for now
• comment/writebacks
  • keep up with new wb versions
  • research URL rewriting for POST
• other feed types
  • RSS 1.0 and 2.0 (adds dates)
  • Atom (done, using atomfeed plugin)
• content negotiatlon for HTML vs XHTML (no, see previous note)
  • look for Accepts: application/xml+xhtml (not sent by Internet Explorer or Safari)
  • html flavour vs xhtml
  • would need to modify Markdown, etc., to generate both flavours (but needed for feeds)
• cache control
  • send Last-modified header (done)
  • send ETag header (done)
  • send Expires header (done)
  • send Cache-control header (done)
  • send Content-length header (done)
  • do If-modified-since check ourselves (done)
  • do If-none-match check ourselves (done)
  • add support for ETag as strong validator (done)

I’ve done a lot of work related to software licensing as part of the Mozilla relicensing project and when I worked at CollabNet. As a result of enduring endess wrangling about licensing terms I’ve been put off complex licensing schemes, and prefer to make my own works available under very liberal terms.

For software I prefer use of the so-called “MIT license” (also known as the “X11 license”) as being the most simple and easy-to-understand license in common use, and the one least likely to cause issues for others who want to reuse my software. For my writings in general I use an even simpler license that grants essentially blanket permissions subject only to a minimal notification requirement.

(I don’t use the Creative Commons attribution license because I don’t see it adding much value for my purposes, and the additional language in the Creative Commons license just gives people more things to argue about. However if for some reason you want to reuse my works under a Creative Commons license or comparable licenses, such as the GNU Free Documentation License or the Open Publication License, just send me a request; I’ll almost certainly grant you whatever permissions you require.)

Content license

Unless otherwise noted the following copyright notice and license terms apply to all normal prose material (i.e., anything other than software and associated documentation) created by me and published on this site:

Copyright © 1994-2006 Frank Hecker (http://www.hecker.org)

You may freely distribute this material in whole or in part, with or without modifications, in the original language or in translation, by itself or as part of other works, in any form and for any purpose, and may permit others to whom you distribute this material to do so as well, provided only that you include the above copyright notice and this permissions notice in all copies or substantial portions of the material.

Software license

Unless otherwise noted the following copyright notice and license terms apply to all software and associated documentation created by me and distributed on this site or as part of this site (including CSS stylesheets, HTML templates, and so on):

Copyright © 1994-2006 Frank Hecker (http://www.hecker.org)

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS,” WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Mini-FAQ

One thing I’ve noticed with open source and free software licensing is that many people don’t seem to take the licenses at face value, but are always asking questions about what they can and can’t do, even when the issue is directly addressed by the license itself. In that spirit here is a “mini-FAQ” intended to forestall such questions:

• “Do I need to ask your permission before I do something with your writings or your software?” No, you do not. However I’d appreciate it if you’d send me an email message if you find anything I’ve created to be of enough interest to you that you’re motivated to redistribute or reuse it; that may motivate me in turn to keep creating new stuff.

• “Can I use your writings or software in commercial products like books or proprietary software?” Yes, you can, and you don’t have to pay me a cent. However if you’d like me to enhance something I’ve written or create new related material then I might be willing to do that for a fee, depending on the nature of the project and whether my work situation permits me to do so.

• “If I use your writings or software in creating my own works, what do I need to do in order to comply with your license terms?” Not much at all: If you use brief extracts then you don’t need to do anything at all; this includes quoting material in blog postings, magazine articles, books and other contexts that would traditionally be considered “fair use.” (However both common courtesy and scholarly tradition would dictate that you attribute the material to me.) If you redistribute entire articles or source code files, or incorporate substantial portions of them in your own work, then the license terms require that you duplicate my copyright notice and permissions notice (i.e., the license terms themselves) in an appropriate place (e.g., accompanying the writings or source code in question).

• ”Can I use your software in software licensed under the GPL, or your writings in documents licensed under the GNU Free Documentation License?” Yes. For software I’m using the MIT/X11 license, which the Free Software Foundation considers to be compatible with the GPL. For my writings I’m using a license that is so liberal I’d be surprised if there were any compatibility issue with the GFDL. However note that using my software (or writings) in a GPL-licensed program (or GFDL-licensed document) does not mean that you can simply replace my license notice with a GPL (or GFDL) license notice; if you want to do that then you need to ask my permission (which I’ll almost certainly grant).

UPDATE: Changed the copyright notice to reflect the new year.

If you’d like to receive full-text articles from this site as they are published, you can subcribe to one or more of the following feeds, in the formats indicated; simply cut and paste the URLs into your feed reader of choice. The Atom feeds are preferred; I maintain the RSS feeds only for older news aggregators that are not yet Atom-enabled.

• All blog articles. This feed includes all articles posted in any of the categories discussed below (Atom or RSS).
• Mozilla-related articles. This feed includes all articles posted in the “mozilla” category (Atom or RSS).
• Blosxom-related articles. This feed includes all articles posted in the “blosxom” category (Atom or RSS).
• Articles about this site and how it’s built. This feed includes all articles posted in the “site” category (Atom or RSS).
• Miscellaneous articles that don’t fit into any of the categories above. This feed includes all articles posted in the “misc” category (Atom or RSS).

Note that I don’t post new articles that often, so you should set your feed reader to check no more than once a day.

The basic principles I tried to follow in creating the this site were as follows:

• The site should be entirely text-based, with minimal or no use of graphics.
• All web pages on the site should validate as HTML 4.01 Strict.
• All web pages on the site should be accessible using URIs that hide the details of the particular content type or page generation mechanism associated with the page.
• The site should be a transparent upgrade from my previous site (created a few years ago), so that all previous URLs should continue to work.

The following sections expand on these points:

Text-based site

When it comes to designing a web site, I have an unfortunate problem: I very much appreciate good graphic design but am utterly incapable of actually doing graphic design. I guess I could try stealing (I mean, “taking inspiration from”) someone else’s design, but unless I did a literal copy I’d probably mess up the design in the process of reusing it.

I’ve therefore decided to avoid the problem entirely and just create an entirely text-based site using a minimal design, minimal enough that hopefully I won’t screw it up too badly. As a side benefit this means that the site should load faster; this may help offset the penalty of doing URL rewriting and dynamic page generation for the weblog.

(Note that if some graphic designer out there wants to help me create a better looking site, whether on a volunteer basis or for a fee, I’d be happy to entertain any offers!)

Use of HTML 4.01 Strict

Since I volunteer for the Mozilla project I feel it’s incumbent on me to support the use of web standards; this would also show off the standards support in Firefox and the browser component of the Mozilla Suite. I then faced the choice between using HTML 4.01 or XHTML 1.0 (or XHTML 1.1 if I wanted to be truly au courant).

In the end I was swayed by Ian Hickson’s comments on XHTML and decided to use HTML 4.01 Strict. I did do some experiments in serving HTML or XHTML depending on the browser; in particular, I implemented a test Blosxom plugin to do content negotiation and send back content of the appropriate type depending on what the browser would accept. (The plugin works by checking the HTTP Accept header and tweaking the Blosxom ”flavour” value appropriately.) However in the end I decided it wasn’t worth the trouble.

(Briefly, the problem is that some browsers that can properly interpret the XHTML content type application/xhtml+xml, like Safari and Opera, don’t indicate an explicit preference for that content type over the HTML content type text/html. But if a browser doesn’t indicate an explicit preference then we have to send HTML; otherwise we’d break Internet Explorer. So we can’t take advantage of the XHTML support in Safari and Opera without doing browser sniffing; the more “pure” approach using just content negotiation works only for Mozilla, Firefox, and other browsers that explicitly indicate a preference for XHTML.)

Cool URIs

My guides in designing a URI scheme have been Tim Berners-Lee’s essay “Cool URIs don’t change” and Jakob Neilsen’s essay “URL as UI.”

I haven’t taken all their advice; in particular, I didn’t want to implement the full date-based URI scheme recommended by Berners-Lee, or the use of a spell-checking web server as recommended by Neilsen.

These are the principles I’m trying to follow:

• allow file extensions to be omitted on all site URIs, e.g., .../site/design-philosophy instead of .../site/design-philosophy.html

• use only lower-case alphanumeric text in URI path components, with a hyphen used to separate words, e.g., design-philosophy instead of design_philosophy, DesignPhilosophy, or (worst of all) design%20philosophy.

• hide the fact that Blosxom (or some other mechanism) is being used to generate pages, e.g., .../site/design-philosophy instead of .../cgi-bin/blosxom.cgi/site/design-philosophy

• use a flat one- or two-level hierarchy for organizing the site, e.g., .../mozilla/foo instead of .../computers/internet/browsers/mozilla/foo

Transparent upgrade

I’ve had my web site active for several years, and in some cases I’ve published articles that other people have linked to. I wanted to turn my home page into the index page for my weblog, and have category index pages under that, e.g., http://www.hecker.org/mozilla/ for my Mozilla-related blog postings. However at the time I needed to ensure that the URIs for existing directories and files would still work.

In particular, I wanted to ensure the following:

• all URIs for existing documents (e.g., http://www.hecker.org/info/bio.html) would continue to return the appropriate document
• all URIs for existing directories (e.g., http://www.hecker.org/writings/) would return either the existing index page or (optionally) an index page for a blog category (e.g., http://www.hecker.org/mozilla/)
• all other URIs would be considered as requests for blog-related pages

Implementation

See the site’s colophon for more information on how I put the above philosophy into practice. (In short, it involves using the Blosxom blogging system and lots of URI rewriting.)

This site is a mixture of static content and dynamic content served through the Blosxom blogging system. I use various URI rewriting rules and a number of Blosxom plugins (some slightly hacked) in order to implement the site according to my personal design philosophy.

Overall implementation

As mentioned above, my site is (for the most part) powered either directly or indirectly by Blosxom. I use three different approaches to serving site content:

• All weblog pages (including the site home page) are dynamically generated by Blosxom.

• Most remaining (non-weblog) pages, eventually including all my writings, are statically generated by Blosxom, with the resulting HTML files then copied into the document root directory.

• The remaining web pages and other files (e.g., images, PDF files, tarballs, and the like) are traditional static web content. Over time I’ll migrate as many of these files as possible into Blosxom (among other things, so I can take advantage of Markdown for text formatting).

The site is hosted by an Intel server running Apache and Linux; since I administer the server I have complete control over the Apache configuration, and implement extensive URI rewriting to integrate the three types of content together in a reasonably seamless manner.

I use Subversion to maintain a version-controlled repository of all the files needed to (re)create the site. (One of the reasons I chose Blosxom was because it stores weblog content as regular text files in the file system–as opposed to in a relational database like a lot of other blog software–and thus is very appropriate for use with a version control system.) I then use GNU Make to automate pushing new content to the site or updating existing content.

URI rewriting

My overall goal is that URIs used to request site content should be entirely independent of the techniques used to serve the content; I use URI rewriting to achieve this goal. In general, if a requested URI refers to existing static content on the site then that content is returned directly by the web server; otherwise Blosxom is invoked to resolve the URL and generate the appropriate content. However there are exceptions; for example, we force URIs referring to certain pre-existing directories (e.g., /mozilla) to be instead interpreted as Blosxom categories.

I implemented the URI rewriting rules directly in the httpd.conf Apache configuration file (actually, in a file included by that file). For more information, including the actual rewriting rules, see my discussion of URI rewriting and canonical URIs.

Extensionless URIs and URI redirection

I wrote two Blosxom plugins to implement my chosen URI scheme. The extensionless plugin allows use of URIs without file extensions to refer to individual entry pages. The canonicaluri plugin forces redirects on category and date-based archive pages if the URI omits a trailing slash, in order to emulate standard Apache behavior for URIs referring to directories; it also forces a redirect if a URI for an individual entry page includes a (spurious) trailing slash or an unneeded .html extension.

Two-column “liquid” layout

I implemented the site layout using the techniques described in the article “Creating Liquid Layouts with Negative Margins” published on the A List Apart site. However I didn’t implement the full set of techniques because I wasn’t using background colors or images.

Here I document the way in which I use URI rewriting (along with redirection and a couple of Blosxom plugins) to help implement my personal design philosophy for my web site. My goal is to create a unified URI space within which static and dynamic content can transparently co-exist, with publicly-visible URIs for human-readable content (i.e., HTML pages) having a canonical form that omits file extensions or other content type specifiers.

Achieving this goal requires solving two separate problems: intermixing dynamic and static content (in my case, Blosxom-generated and non-Blosxom content) in the same URI hierarchy, and recognizing and enforcing preferred canonical forms for URIs.

Intermixing dynamic and static content

As an example of freely intermixing dynamically-generated content and static content (e.g., images) within the same URI hierarchy, consider a Blosxom-based web site where http://www.example.com/foo is a Blosxom category, /foo/bar.html is the HTML page displayed for an individual Blosxom entry in that category, and /foo/baz.jpg is an image referenced by that entry. (We assume that the site is already using one of the suggested techniques for hiding the /cgi-bin/blosxom.cgi part of the URI.) With Blosxom there are at least two possible approaches to support such intermixing.

One approach would be to invoke Blosxom (i.e., blosxom.cgi) for each and every URI processed, and then to use the binary plugin or the static_file plugin based on it; these Blosxom plugins check to see if a requested URI corresponds to an existing file in the file system and, if so, they return the file’s contents as the output (as opposed to trying to generate a Blosxom page).

The second possible approach is the reverse: Have Apache serve up existing files (and indices for existing directories), and invoke Blosxom only when the URI references a file (or directory) that doesn’t exist. This is the approach I’ve taken, for various reasons; in particular, I wanted to avoid the overhead of invoking Blosxom for each and every URI. This approach is also compatible with a strategy of converting all or part of the Blosxom-managed content into static files. For example, one could run blosxom.cgi in static mode to generate files and directories under the Apache document root; Apache would then serve up those files and directories just as it would non-Blosxom content.

Recognizing and enforcing canonical URIs

We want to enforce the following rules for how URIs should be represented:

• URIs used to access HTML content for directories, Blosxom categories, and Blosxom date-based archive pages should have no index.html component and one (and only one) trailing slash:

    http://www.example.com/foo/
    http://www.example.com/foo/2004/11/14/
  

• URIs used to access HTML content for static web pages and individual Blosxom entries should have no .html extension and no trailing slash:

    http://www.example.com/foo/bar
  

• URIs used to access all other (non-HTML) content should have filename extensions; index.* components should be included for directories, Blosxom categories, and Blosxom date-based archives, etc.:

    http://www.example.com/foo/baz.png
    http://www.example.com/foo/index.rss
    http://www.example.com/foo/2004/11/14/index.rss
  

Enforcing these conventions is relatively straightforward: if a requested URI does not follow the above rules then we simply force a redirect to the canonical URI. However determining whether a URI is already in the proper canonical form or not is less straightforward, especially when we intermix Blosxom and non-Blosxom content.

For example, if the URI http://www.example.com/foo/bar is requested then we have to do the following checks:

• Is /foo/bar an existing directory?
• Is there an existing HTML file /foo/bar.html?
• Is /foo/bar a Blosxom category?
• Is there an individual Blosxom entry /foo/bar.html?

In practice we do these checks in the order shown, both to eliminate ambiguity (for example, if there’s a directory /foo/bar and also a Blosxom entry /foo/bar.html) and also because it’s easier to implement: The first two checks are done by Apache in the course of doing URI rewriting, and the second two checks are done by a Blosxom plugin once the URI has been passed off to Blosxom for processing.

Strategy

Here’s the overall strategy we follow in doing URI rewriting:

• We divide requests into those that can be satisfied by returning a static file or directory index and those that are for dynamically-generated content; the latter are rewritten into URIs that invoke the necessary CGI script (blosxom.cgi). Note that in some cases we can make an immediate determination as to whether content is static or dynamic, while in other cases we have to wait for the results of subsequent URI rewriting rules.

• If a request references an existing directory then if necessary we force a redirect to the canonical URI for the directory, namely a URI with one (and only one) trailing slash after the directory name.

• If a request is for an existing index.html file then we force a redirect to the canonical URI for the directory in which that file is located.

• If a request is for any other existing HTML file then we allow and require that the .html file extension be omitted. If the .html file extension is included in the requested URI then we force a redirect to the canonical URI for the file, namely a URI that omits the .html file extension and has no trailing slashes.

• If a request is for an existing file (or a symbolic link to a file) then it is handled by Apache in the normal way. Any other requests are passed to Blosxom for processing.

• Blosxom (actually, a Blosxom plugin) then performs its own set of checks on URIs, and rewrites URIs and/or forces redirects if needed.

URI rewriting quirks

Before I discuss the URI rewriting rules themselves, here are various points to keep in mind when reading the rules; some of these points are not necessarily immediately apparent from reading the documentation for the mod_rewrite module and the Apache URL Rewriting Guide:

• In our case we have root access to the system and can put our rewriting rules in the master Apache configuration file (httpd.conf). These rules will not work as is if you do not have root access and have to put your rewriting rules in a .htaccess file. (I don’t have time to revise the rules to work for the .htaccess case, but perhaps someone else can do so; unfortunately URI rewriting in a .htaccess file is much more complicated than when done in httpd.conf.)

• RewriteRule directives are evaluated in order looking for a match of the URI against the left-hand side of the RewriteRule directive. RewriteCond directives are looked at only if the corresponding RewriteRule directive matches. If the left-hand side of the RewriteRule directive matches and the corresponding RewriteCond directives (if any) evaluate true, then the URI is rewritten into the form specified by the right-hand side of the RewriteRule directive. Otherwise Apache just goes on to the next RewriteRule.

• The URI matched against the RewriteRule directives is not the full URI but rather just the path component of the URI; it does not include either the hostname part or any query string. Thus, for example, if the original request was for http://www.example.com/foo/bar?flav=baz then the RewriteRule directives will be matched against /foo/bar. (At least this is true in my case; this works slightly differently if you have to put your rules in a .htaccess file.)

• Rule matching is done using regular expressions modeled on those in Perl. However Apache doesn’t support the full range of Perl regular expressions, and in particular doesn’t support any options to address the “greedy matching” problem. For example, if you match URIs against an expression like ^(.*)//?$ (for example, to detect excess trailing slashes) then for a URI like /foo// Apache will assign $1 to be /foo/ instead of /foo as we’d like. We have to hack around this problem as described in the next section.

• Once we have rewritten a URI to our satisfaction we normally want to stop URI rewriting at that point, and use the the L (“last”) flag to do this; otherwise Apache would continue evaluating RewriteRule directives looking for further matches. However using L by itself is normally not sufficient to get Apache to do the right thing; typically we have to include other flags as discussed below.

• Normally once rewriting ends Apache will simply take the (possibly rewritten) path component of the URI and append it to the defined “document root” value (i.e., the directory where static web content is located). This causes a problem if the URI actually refers to a path for which an Apache Alias or ScriptAlias directive is defined. (For example, on my server /cgi-bin is not in the main document root, but is located elsewhere as defined by a ScriptAlias directive.) To fix this we use the PT (“pass through”) flag where needed to tell Apache to first pass the URI through to the mod_alias module.

• If the URI refers to an existing directory then after the first round of rewriting ends the Apache mod_dir module will initiate so-called “subrequests” for URIs with index.html, etc., appended, and each subrequest will start a new round of rewriting. We don’t want to have any of our rewriting rules invoked in that case (among other things, this can lead to problems with looping), so we also use the NS (“no subrequest”) flag to note that our rules should not be invoked for such internal subrequests.

• In some cases we don’t simply want to rewrite the URI, we want to correct perceived mistakes in how the URI was originally requested. (For example, we want all URIs referring to existing directories to end in one–and only one–trailing slash.) For these cases we use the R flag to tell Apache to redirect the user’s browser to a new and corrected URI. (We actually use R=301 to specify the HTTP code returned, in this case a code meaning “the URI has permanently moved.”) In combination with the L flag this immediately ends rewriting for the original URI; a new round of rewriting starts once the browser requests the new URI.

The rewriting rules

Here are the actual Apache URI rewriting rules we use, in order of evaluation and application:

1. We first enable the rewriting engine and specify a location for logging rewriting actions:

    RewriteLog logs/hecker_error_log
    RewriteLogLevel 0
    RewriteEngine on
   

   Note that RewriteLogLevel should be set to a non-zero value to enable logging; a loglevel value of 9 produces lots of output and can be very useful when debugging rewriting rules and/or learning how rewriting works.

   Also note that the RewriteBase directive is not needed here because we are specifying rewriting rules in the httpd.conf configuration file; RewriteBase is typically needed only when specifying rewriting rules in a .htaccess file.

2. We start the process of handling trailing slashes by stripping all but the last two trailing slashes off of all URIs:

    RewriteRule  ^(.*)///  $1//  [N,NS]
   

   The form of this rule is a hack to get around the “greedy matching” problem described above, which prevents us from using the regular expression ^(.*)//+$ for this purpose. For any URI ending in at least three slashes, we rewrite the URI to remove a trailing slash and then use the N (“next round”) flag to restart rewriting from the beginning. Since this is the first rule this simply repeats the rule until no more than two trailing slashes remain on the URI.

   Why stop at two, as opposed to removing all but one slash? Because we want to keep track of URIs with excess trailing slashes and force a redirect further on down; hence we leave at least one excess slash on the URI.

3. We protect against potential XST cross-site scripting attacks by rejecting all HTTP requests with either the TRACE or TRACK methods. (See the relevant WhiteHat Security press release and a related VulnWatch list posting.) The F flag causes Apache to immediately send back an HTTP response of 403 (“FORBIDDEN”). (The L flag is not needed here because the F flag causes rewriting to stop automatically.)

    RewriteCond  %{REQUEST_METHOD}  ^(TRACE|TRACK)
    RewriteRule  .*  -  [F,NS]
   

4. We eliminate duplicate trailing slashes at the end of URIs by redirecting to a new URI with only one trailing slash, to enforce canonical forms for directory URIs and also get rid of some potential problems when requesting Blosxom pages.

   Note that the first rule above guarantees that by the time we get to this rule we’ll never see more than two trailing slashes on a URI.

    RewriteRule  ^(.*)//$  $1/  [L,R=301,NS]
   

5. We don’t attempt to do rewriting of URIs that are handled separately and do not correspond to either Blosxom content or content in our document root. In particular, we don’t attempt to rewrite /cgi-bin/... or /usage/... URIs (for which we define aliases for the virtual host associated with the site) or /icon/... URIs (for which httpd.conf defines a server-wide alias). Instead we just pass these URIs through to be handled by mod_alias.

   Note that there is also a server-wide alias for /manual/ but we ignore this since we aren’t serving up a copy of the Apache documentation. (We include /icons/ because it is needed for auto-generated directory listings.)

    RewriteRule  ^/(cgi-bin|icons|usage)(/.*)?$  -  [L,PT,NS]
   

6. We have Blosxom override the directory index for / (the home page) and other existing directories that should be treated as Blosxom categories instead. (References to other stuff under those directories, including index.html pages, is handled below.)

   Note that these rewrite rules must come first in order to handle these special cases before we check for existing directories in general. The URIs may or may not have a trailing slash; we need to handle both cases. We pass any trailing slash on to Blosxom, which can then force a redirect if the trailing slash is omitted; we do it this way (rather than forcing a redirect here) so that such redirection can be done consistently for all Blosxom categories.

   Also note that in order for Blosxom to produce the correct results the directories in question should not have any index.* files within the directory. Further on down we explicitly handle the case where an index.html page is requested (by redirecting to the canonical URI without index.html) but references to other index.* pages (e.g., /misc/index.rss) will not return the corresponding Blosxom page if a file of that name is already present in the directory.

    RewriteRule  ^(/? )$  /cgi-bin/blosxom.cgi$1  [L,PT,NS]
    RewriteRule  ^/(blosxom|misc|mozilla)(/? )$
            /cgi-bin/blosxom.cgi/$1$2  [L,PT,NS]
   

7. We next check to see if the URI corresponds to an existing directory under the document root. If so and the URI has a trailing slash then we simply stop rewriting and use the URI as is; otherwise we add a trailing slash and force a redirect to the new URI.

   Note that we can’t use %{REQUEST_FILENAME} in the directory existence check because that variable has not yet been set; hence we have to explicitly append the URI to the document root pathname.

    ReWriteCond  %{DOCUMENT_ROOT}/$1  -d
    RewriteRule  ^/(.*)/$  -  [L,NS]
   
    ReWriteCond  %{DOCUMENT_ROOT}/$1  -d
    RewriteRule  ^/(.*)$  /$1/  [L,R=301,NS]
   

8. If the URI is explicitly requesting an index.html file for an existing directory (e.g., /foo/index.html) then we force a redirect to the canonical URI for that directory (e.g., /foo/).

   Note that we catch the case where the URI (incorrectly) includes a trailing slash (e.g., /foo/index.html/), and redirect that to the canonical URI as well. Note also that skipping this rule on internal subrequests is particularly important; otherwise we’d cause major looping problems with URIs requesting directory indices.

    ReWriteCond  %{DOCUMENT_ROOT}$1  -d
    RewriteRule  ^(.*)/index\.html(/? )$  $1/  [L,R=301,NS]
   

9. We check to see if the URI is explicitly requesting an existing HTML file (e.g., /foo/bar.html where bar.html exists). If so then we force a redirect to the canonical URI for the file, without the .html file extension (e.g., /foo/bar).

   As with the previous rule, we properly handle the case where the URI (incorrectly) includes a trailing slash, and we make sure to avoid problems with internal subrequests for directory index URIs.

   Finally, note a minor bug in the rule: It incorrectly rewrites a URI like /foo/.html that references a hidden file named .html; I chose to ignore this uncommon (and arguably nonsensical) case.

    ReWriteCond  %{DOCUMENT_ROOT}/$1.html  -f
    RewriteRule  ^/(.*)\.html/?$  /$1  [L,R=301,NS]
   

10. We check to see if the URI corresponds to an existing HTML file after adding a .html extension. If so, we rewrite the URI to include the extension and pass it through to Apache.

Again we properly handle the case where a trailing slash has been incorrectly added.  Also note that we use the `OR` flag on the RewriteCond directive because we are checking to see if the URI references a regular file *or* a symbolic link; by default all RewriteCond directives must evaluate true in order for the corresponding rewriting rule to be invoked.

    RewriteCond  %{DOCUMENT_ROOT}/$1.html  -f [OR]
    RewriteCond  %{DOCUMENT_ROOT}/$1.html  -l
    RewriteRule  ^/(.*)/$  /$1.html  [L,R=301,NS]

    RewriteCond  %{DOCUMENT_ROOT}/$1.html  -f [OR]
    RewriteCond  %{DOCUMENT_ROOT}/$1.html  -l
    RewriteRule  ^/(.*)$  /$1.html  [L,NS]

11. We check to see if the URI corresponds to any other (non-HTML) existing file or symbolic link and, if so, we force a redirect if a trailing slash is present.

    RewriteCond %{DOCUMENT_ROOT}/$1 -f [OR] RewriteCond %{DOCUMENT_ROOT}/$1 -l RewriteRule ^/(.*)/$ /$1 [L,R=301,NS]

12. Finally, we pass the URI on to Blosxom if it does not correspond to an existing (non-HTML) file or symlink.

    RewriteCond %{DOCUMENT_ROOT}/$1 !-f RewriteCond %{DOCUMENT_ROOT}/$1 !-l RewriteRule ^/(.*)$ /cgi-bin/blosxom.cgi/$1 [L,PT,NS]

This concludes the rewriting rules.

After (Apache) rewriting ends

Once Apache has concluded all rewriting (including further rewriting done for new requests due to redirects) all URIs should be in one of the following forms, and are handled as indicated:

• Canonical URIs for existing directories (e.g., /foo/). Each such URI is subsequently processed by the mod_dir module, which will attempt to look for a directory index file as specified by the DirectoryIndex directive. The mod_dir module may generate internal subrequests, e.g., for /foo/index.html, but these will not invoke our rewriting rules.

  If mod_dir cannot find an index file then a directory listing will be generated by the mod_autoindex module if the Indexes option is specified for the Options directive.

• URIs for existing HTML files (e.g., /foo/bar.html) rewritten from the canonical form of such URIs (e.g., /foo/bar). Each such URI is handled normally by Apache (without going through mod_alias, since there’s no need to do so).

• Canonical URIs for existing non-HTML files (e.g., /foo/baz.png). Each such URI is handled normally by Apache (again without going through mod_alias).

• URIs to be handled by Blosxom (e.g., /cgi-bin/blosxom.cgi/foo/). Each such URI is passed to mod_alias (to determine the location of the cgi-bin directory) and then the blosxom.cgi script is invoked with the path specified (e.g., /foo). Note that the path in question is not necessarily (yet) in canonical form, except that it is guaranteed not to have more than one trailing slash.

• Other (non-Blosxom) cgi-bin URIs or other URIs needing further translation (e.g., /icon URIs for images in auto-generated directory listings). Each such URI is passed to mod_alias.

Canonical URIs in Blosxom

Once a URI is passed to Blosxom then we have to do the same sorts of URI checks, rewriting, and/or redirection done by the Apache URI rewriting rules. We divide this work into two separate plugins:

• The extensionless plugin checks requests for which the requested URI lacks a flavour extension (e.g., /foo/bar) and adds the appropriate flavour extension (.html in our case) to the variable $blosxom::path_info if there is an individual entry corresponding to that URI.

• The canonicaluri plugin checks URIs to see if they are in canonical form and forces a redirect if necessary.

For more information see the documentation for those plugins.

I’ve tried to make this site accessible to as many people as possible; here I describe the accessibility features of this site. (This statement is based on Mark Pilgrim’s accessibility statement.) If you have any questions or comments about the accessibility of this site, feel free to email me at the address found elsewhere on this site.

Access keys

Most browsers support jumping to specific links by typing special key combinations defined on the web site. On Windows, you can press ALT + an access key; on Macintosh, you can press Control + an access key.

The home page and all archives define the following access keys:

• Access key 1: Home page
• Access key 4: Search box
• Access key 9: Feedback
• Access key 0: Accessibility statement

(Note that I didn’t define an access key to skip to the main content because the main content is already the first thing on the page.)

Standards compliance

1. I intend to ensure that all pages are Bobby AAA approved. More on that later as I complete the necessary work.
2. I intend to ensure that all pages are Section 508 compliant. More on that later as I complete the necessary work.
3. The home page and blog archives validate as HTML 4.01 Strict. (Some older pages on the site have not yet been modified to validate properly.)
4. The home page, blog archives, and other pages use structured semantic markup. For example, on pages with more than one entry H2 tags are used for individual post titles, so that JAWS users can skip to the next post with ALT+INSERT+2.

Navigation aids

1. All blog archive pages have rel=home links to aid navigation in text-only browsers and screen readers; I may add rel=previous, next, and up links in the future. (Unfortunately prev and next in particular are not simple to implement in Blosxom, the blogging system I’m using.) Mozilla users can take advantage of this feature by selecting the View menu, Show/Hide, Site Navigation Bar, Show Only As Needed (or Show Always). Opera 7 has similar functionality.
2. The home page and all archive pages include a search box (access key 4).

Links

1. Many links have title attributes which describe the link in greater detail, unless the text of the link already fully describes the target (such as the headline of an article).
2. Whever possible, links are written to make sense out of context. Many browsers (such as JAWS, Home Page Reader, Lynx, and Opera) can extract the list of links on a page and allow the user to browse the list, separately from the page.
3. Link text is never duplicated; two links with the same link text always point to the same address.
4. There are no javascript: pseudo-links. All links can be followed in any browser, even if scripting is turned off.
5. There are no links that open new windows without warning.

Images

1. With one exception (a photo for my biography page) this site does not use images at all.

Visual design

This site and all its archives use cascading style sheets for visual layout.

1. The style sheets for this site do not specify a base font size, and use relative font sizes to specify the appearance of headings and related text. Text on this site should be resizable in any browser that permits text resizing.
2. If your browser or browsing device does not support stylesheets at all, the content of each page is still readable.

References

In creating this site I made use of Mark Pilgrim’s Dive Into Accessibility book and related materials. See the book for a complete list of other references.