Perpetual motion with Apache

A tale of Apache support

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 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 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 or 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 or

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

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

Other stories you might like

  • Experts: AI should be recognized as inventors in patent law
    Plus: Police release deepfake of murdered teen in cold case, and more

    In-brief Governments around the world should pass intellectual property laws that grant rights to AI systems, two academics at the University of New South Wales in Australia argued.

    Alexandra George, and Toby Walsh, professors of law and AI, respectively, believe failing to recognize machines as inventors could have long-lasting impacts on economies and societies. 

    "If courts and governments decide that AI-made inventions cannot be patented, the implications could be huge," they wrote in a comment article published in Nature. "Funders and businesses would be less incentivized to pursue useful research using AI inventors when a return on their investment could be limited. Society could miss out on the development of worthwhile and life-saving inventions."

    Continue reading
  • Declassified and released: More secret files on US govt's emergency doomsday powers
    Nuke incoming? Quick break out the plans for rationing, censorship, property seizures, and more

    More papers describing the orders and messages the US President can issue in the event of apocalyptic crises, such as a devastating nuclear attack, have been declassified and released for all to see.

    These government files are part of a larger collection of records that discuss the nature, reach, and use of secret Presidential Emergency Action Documents: these are executive orders, announcements, and statements to Congress that are all ready to sign and send out as soon as a doomsday scenario occurs. PEADs are supposed to give America's commander-in-chief immediate extraordinary powers to overcome extraordinary events.

    PEADs have never been declassified or revealed before. They remain hush-hush, and their exact details are not publicly known.

    Continue reading
  • Stolen university credentials up for sale by Russian crooks, FBI warns
    Forget dark-web souks, thousands of these are already being traded on public bazaars

    Russian crooks are selling network credentials and virtual private network access for a "multitude" of US universities and colleges on criminal marketplaces, according to the FBI.

    According to a warning issued on Thursday, these stolen credentials sell for thousands of dollars on both dark web and public internet forums, and could lead to subsequent cyberattacks against individual employees or the schools themselves.

    "The exposure of usernames and passwords can lead to brute force credential stuffing computer network attacks, whereby attackers attempt logins across various internet sites or exploit them for subsequent cyber attacks as criminal actors take advantage of users recycling the same credentials across multiple accounts, internet sites, and services," the Feds' alert [PDF] said.

    Continue reading

Biting the hand that feeds IT © 1998–2022