Feeds

Perpetual motion with Apache

A tale of Apache support

High performance access to file storage

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

High performance access to file storage

More from The Register

next story
Windows 8.1, which you probably haven't upgraded to yet, ALREADY OBSOLETE
Pre-Update versions of new Windows version will no longer support patches
Android engineer: We DIDN'T copy Apple OR follow Samsung's orders
Veep testifies for Samsung during Apple patent trial
OpenSSL Heartbleed: Bloody nose for open-source bleeding hearts
Bloke behind the cockup says not enough people are helping crucial crypto project
Half of Twitter's 'active users' are SILENT STALKERS
Nearly 50% have NEVER tweeted a word
Windows XP still has 27 per cent market share on its deathbed
Windows 7 making some gains on XP Death Day
Internet-of-stuff startup dumps NoSQL for ... SQL?
NoSQL taste great at first but lacks proper nutrients, says startup cloud whiz
Microsoft lobs pre-release Windows Phone 8.1 at devs who dare
App makers can load it before anyone else, but if they do they're stuck with it
US taxman blows Win XP deadline, must now spend millions on custom support
Gov't IT likened to 'a Model T with a lot of things on top of it'
prev story

Whitepapers

Mainstay ROI - Does application security pay?
In this whitepaper learn how you and your enterprise might benefit from better software security.
Five 3D headsets to be won!
We were so impressed by the Durovis Dive headset we’ve asked the company to give some away to Reg readers.
3 Big data security analytics techniques
Applying these Big Data security analytics techniques can help you make your business safer by detecting attacks early, before significant damage is done.
The benefits of software based PBX
Why you should break free from your proprietary PBX and how to leverage your existing server hardware.
Mobile application security study
Download this report to see the alarming realities regarding the sheer number of applications vulnerable to attack, as well as the most common and easily addressable vulnerability errors.