Feeds

Perpetual motion with Apache

A tale of Apache support

The essential guide to IT transformation

Column When you hang around in an Apache support forum, you get all sorts of questions. At best, some really interesting discussions; at worst irrelevant nonsense. But always, a stream of newbies with FAQs. To be clear, when I say newbie, I mean exactly that: someone who is new to a particular subject. Most of them are on the learning curve, and the regulars are generally happy to help them. A few just expect you to do everything for them, and are more likely to go away disappointed.

One such forum is the #apache channel on IRC at freenode.net. IRC is a great medium when you want the immediacy of chat. And on #apache, we have a 'bot called fajita (commonly anthropomorphised to a "she") who does a splendid job of answering FAQs, relieving the regulars of tedious typing.

Now, I don't want to write about the topics we deal with there. That's what documentation and tutorials are for, and typically the best way to help a newbie is to point them to a relevant webpage (a job fajita does nicely). But there's a somewhat more interesting job: diagnosing and fixing what's in a questioner's mind. That's not something the bot can take charge of, and of course finding a human willing and able to put in the time and effort is a hit-and-miss affair.

At the risk of sounding like Tristram Shandy, let me digress into why we may seem unhelpful when a question comes across as "help me shoot myself in the foot". It's a lesson many people in charge of multi-million projects sorely need. So, an anecdote. I took a job in 1992 to develop a piece of software for a large, international research institution. I was one of three people recruited by the same employer for development jobs at the client in question. Each of us was given the taks of developing a different system. The client was firmly into formal methods of software development, with a specified process based on a series of requirements, architecture and design documents. Each of the three of us took a different approach:

  • J. implemented his package exactly to spec. He did a good job and delivered a working system, together with all the documents (though the latter were largely a token effort). His system was made operational (and for all I know still is), but no-one ever used it.
  • A. implemented his package to process. He followed the formal cycle with attention to detail in every respect. He produced mountains of paperwork, but the software was never completed. He got promotion to a managerial role.
  • Yours truly took a proactive attitude. Instead of just implementing exactly to spec, I questioned the "user requirements" where it seemed unclear that they'd asked for the right thing[Ed: In my opinion, questioning and refining the "user requirements" is one of the first steps in "early defect removal", aka "testing" - and is an absolutely essential part of the development process]. The system I produced worked, and subsequently became a component of a number of other systems in fairly heavy use.

Setting aside the obvious Dilbertian conclusion, the moral of this story is that insight is more important than process if the end product is to be genuinely useful. No matter how well you do what you're asked to, it's only useful insofar as you were solving the right problem.

Anyway, let's get back to Apache, and a paraphrase of a reasonably common type of session in which I tried to help someone. He starts, as do many, with the mistake of assuming a solution rather than addressing the underlying problem.

newbie: I need some help with mod_rewrite
newbie: Is RewriteRule foo\.example\.com www.example.com right?

That begs the question, right for what? It's an important question, because of the obvious subtext: "It didn't quite do what I wanted, so how do I fix it?"

Well, as with so many mod_rewrite questions, there's a simpler solution to what was actually asked. Let's try it:

niq: redirect?
fajita: redirect is http://httpd.apache.org/docs-2.0/mod/mod_alias.html#redirect or http://httpd.apache.org/docs/mod/mod_alias.html#redirect or see 'Redirect Context'
newbie: No, I can't use that.
newbie: That sends a redirect. I want to do it all on the server.

It worked. Newbie has told us why his rewrite rule doesn't do what he wants. He wants the server to treat one domain as another. OK, there's a simple solution to that, too:

niq: serveralias
fajita: serveralias is http://httpd.apache.org/docs-2.0/mod/core.html#serveralias or http://httpd.apache.org/docs/mod/core.html#serveralias

Now we've effectively covered all our bases. Redirect works by sending an HTTP redirect; ServerAlias internally treats one server name as equivalent to another. Mod_rewrite offers exactly the same options.

But, crucially, these two options are also exactly what HTTP offers. So, if neither of them "works", then no amount of mod_rewrite wizardry is going to fix it either. The difference is that whereas Redirect and ServerAlias are sufficiently simple that our newbie can see what they do (and don't do), mod_rewrite offers deep voodoo, and with it the enticing prospect of defeating the basic laws of HTTP. By analogy, let's call it perpetual motion.

Let's see where this is leading:

newbie: That doesn't work for me either. I need the server variable set to foo.example.com

OK, now we're getting somewhere. Actually, serveralias does exactly what he just asked for, and he'll realise that in a moment if he's bright enough to be helped. Of course, his thinking now is probably confused by too much staring at a problem. Anyway, at this point I shut up. Maybe to give him pause for reflection. Or maybe just because taking the discussion any further was going to take more time than I had for IRC. Well, actually both. As it happens, someone else stepped in:

other-regular: what exactly is the problem you're trying to solve?

On the web, HTTP is like the laws of nature: you can't just ignore it and expect it to go away. You can work around it in many ways, but you're better off working with it. Define your problem, and make sure it's feasible within the constraints of HTTP. Only when you have a well-specified problem should you look to Apache - let alone mod_rewrite - for a solution.

Actually, Apache can transcend HTTP. But that gets beardy (not to mention the paunch and sandals), and isn't something you can do with the likes of mod_rewrite or PHP. Maybe I'll discuss it in another article.

Copyright © 2006 Nick Kew

Secure remote control for conventional and virtual desktops

More from The Register

next story
The Return of BSOD: Does ANYONE trust Microsoft patches?
Sysadmins, you're either fighting fires or seen as incompetents now
Microsoft cries UNINSTALL in the wake of Blue Screens of Death™
Cache crash causes contained choloric calamity
Munich considers dumping Linux for ... GULP ... Windows!
Give a penguinista a hug, the Outlook's not good for open source's poster child
Time to move away from Windows 7 ... whoa, whoa, who said anything about Windows 8?
Start migrating now to avoid another XPocalypse – Gartner
You'll find Yoda at the back of every IT conference
The piss always taking is he. Bastard the.
HANA has SAP cuddling up to 'smaller partners'
Wanted: algorithm wranglers, not systems giants
prev story

Whitepapers

Endpoint data privacy in the cloud is easier than you think
Innovations in encryption and storage resolve issues of data privacy and key requirements for companies to look for in a solution.
Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Top 8 considerations to enable and simplify mobility
In this whitepaper learn how to successfully add mobile capabilities simply and cost effectively.
Solving today's distributed Big Data backup challenges
Enable IT efficiency and allow a firm to access and reuse corporate information for competitive advantage, ultimately changing business outcomes.
Reg Reader Research: SaaS based Email and Office Productivity Tools
Read this Reg reader report which provides advice and guidance for SMBs towards the use of SaaS based email and Office productivity tools.