Apache DevCenter
oreilly.comSafari Books Online.Conferences.


Apache Cookbook

A Day in the Life of #Apache
The history of mod_imap

by Rich Bowen, coauthor of Apache Cookbook

Editor's note: Rich Bowen is back this week to help Apache users with yet another common dilemma. In this latest article in the series based on his conversations on the IRC channel #apache, Rich takes you on an interesting trip through the history of mod_imap, and why some modules hang around long after they're no longer in use.

#apache is an IRC channel that runs on the irc.freenode.net IRC network. To join this channel, you need to install an IRC client (XChat, MIRC, and bitchx are several popular clients) and enter the following commands:

/join #apache

Day Four

Following my last talk, I encountered some renewed interest in mod_imap. It's enabled by default in every binary distribution of Apache that I'm aware of, and it's also enabled by default when you build from source.

Have you ever used mod_imap? No. I didn't think so.

In fact, I'd suspect that many of you have not even heard of mod_imap and are thinking, cool, an email module for Apache! Well, don't get too excited. It's not that. But this may require a little bit of explanation.

Related Reading

Apache Cookbook
By Ken Coar, Rich Bowen

<heavencent> Anyone here used mod_imap?
<DrBacchus> Long, long ago.
<heavencent> How did you implement it?
<DrBacchus> Well ... do you actually know what mod_imap does?
<heavencent> I'm trying to figure that out. I assume it accesses imap servers and displays information via a browser.
<DrBacchus> No. It is not related to imap at all.
<DrBacchus> heavencent: It does server-side image maps.
<heavencent> ah ...
* heavencent blushes
<DrBacchus> It has been an obsolete module since at least 1996, when Netscape 0.9 came out with client-side image maps.
<DrBacchus> fajita: mod_imap
<fajita> mod_imap is http://httpd.apache.org/docs-2.0/mod/mod_imap.html or an old, deprecated module that virtually no one needs anymore.

Now, it's entirely possible that I have my history wrong there. I don't actually remember the version number when client-side imagemaps first appeared. But I remember being very excited about it. And I remember that for about a year, every web site had at least one of them, to the point that it even got very irritating. Then folks discovered JavaScript, and since then, interest in imagemaps has waned to the point that you almost never see them.

But that's all rather peripheral. We were talking about mod_imap.

An imagemap is an image in an HTML page, with the magical property that clicking on different parts of the image will take you to different URLs. The map portion of the imagemap is a listing of coordinates defining the various areas of the image, and the URLs to which those areas are mapped. This will look something like:

<map name="example">
  <area shape="rect" coords="15,8,135,39" 
  <area shape="rect" coords="245,86,504,143" 
  <area shape="rect" coords="117,122,175,158" 
  <area shape="default" nohref>

This block goes in your HTML file, and is accompanied by an image like this:

<img border="0" src="image.gif" usemap="#example">

When you click on the image, the browser magically maps that click to the coordinates of the click, and to the URL that you've associated with those coordinates.

That is, that's the way to do it now. But, in the Golden Days, when men were men, and we did things the hard way or not at all, it wasn't nearly that simple. Instead, back then, when you clicked on the image, it would send the coordinates back to the server, and the server had to figure out what that click meant.

So, for today's lesson, we'll take you on a little jaunt back in history, so that you can ponder why mod_imap is enabled by default.

Rather than putting the map in the HTML file, you'll put it on the server. The HTML imagemap above would be rendered as the .map file below, into which you will put:

rect http://cui_www.unige.ch/w3catalog    15,8    135,39
rect gopher://rs5.loc.gov/11/global       245,86  504,143  
rect http://nearnet.gnn.com/GNN-ORA.html  117,122 175,158

By the way, the above map is shamelessly stolen from the NCSA documentation, and contains a gopher reference in order to lend a little bit of ironic humor to the whole situation. Did you get it? This old-fogey humor can be a little hard to sustain ...

So ... anyways.

The file above would be saved on your Apache server as, say, example.map, and the image in your HTML page would now look like this:

<a href="example.map">
  <img src="image.gif" ISMAP>

And, finally, on your Apache server, you'll need to make one configuration change in order to get Apache to handle .map files correctly. You'll probably find this line already in your configuration file, but commented out.

AddHandler imap-file .map

Now, when you hover your mouse above the image, you should see a URL in your status bar containing something like ?118,133 on the end of it. When you click, there will be a small pause as the browser asks the server what those coordinates correspond to, and then redirects you to the new location.

<sockmonk> DrBacchus: if you write that imagemap tutorial, will that undercut your argument for removing mod_imap from the default module list?

Yeah, I may have backfired here a little bit. The goal here was to persuade you that there was no value in having mod_imap at all. And, indeed, that is the case. But it was kinda neat to take a moment to look back in history at why it's there in the first place.

During the few years when every web site was using server-side imagemaps, it was essential that this module be available, and it made sense for it to be part of the default build. Later, after that need went away, we're reluctant to remove default modules, even when they are seldom used. Once a module is part of that default list, people seem to expect it to always be part of that default list, and when it goes away, folks complain. So the decision was made to leave it there, even though it's been mostly unused since about 1996 or so.

Check back here again next month to learn how yet another #apache problem gets resolved.

Rich Bowen is a member of the Apache Software Foundation, working primarily on the documentation for the Apache Web Server. DrBacchus, Rich's handle on IRC, can be found on the web at www.drbacchus.com/journal.

O'Reilly & Associates recently released (November 2003) Apache Cookbook.

Return to the Apache DevCenter.

Sponsored by: