Perpetual motion with Apache

A tale of Apache support

Reducing security risks from open source software

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

The Power of One eBook: Top reasons to choose HP BladeSystem

More from The Register

next story
NO MORE ALL CAPS and other pleasures of Visual Studio 14
Unpicking a packed preview that breaks down ASP.NET
Cheer up, Nokia fans. It can start making mobes again in 18 months
The real winner of the Nokia sale is *drumroll* ... Nokia
Mozilla fixes CRITICAL security holes in Firefox, urges v31 upgrade
Misc memory hazards 'could be exploited' - and guess what, one's a Javascript vuln
Put down that Oracle database patch: It could cost $23,000 per CPU
On-by-default INMEMORY tech a boon for developers ... as long as they can afford it
Google shows off new Chrome OS look
Athena springs full-grown from Chromium project's head
Apple: We'll unleash OS X Yosemite beta on the MASSES on 24 July
Starting today, regular fanbois will be guinea pigs, it tells Reg
HIDDEN packet sniffer spy tech in MILLIONS of iPhones, iPads – expert
Don't panic though – Apple's backdoor is not wide open to all, guru tells us
prev story


Top three mobile application threats
Prevent sensitive data leakage over insecure channels or stolen mobile devices.
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.
Boost IT visibility and business value
How building a great service catalog relieves pressure points and demonstrates the value of IT service management.
Designing a Defense for Mobile Applications
Learn about the various considerations for defending mobile applications - from the application architecture itself to the myriad testing technologies.
Build a business case: developing custom apps
Learn how to maximize the value of custom applications by accelerating and simplifying their development.