httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@ai.mit.edu (Robert S. Thau)
Subject Re: mod_imap.c
Date Mon, 03 Jul 1995 16:04:15 GMT
   Date: Mon, 03 Jul 1995 13:09:09 -0500
   From: Randy Terbush <randy@zyzzyva.com>

   Well, after some brain pounding, I actually have a working imagemap
   module for Shambhala.  This version does have one added feature that
   Brian's imagemap2 does not offer; you don't need a .imap file in
   every directory that uses imagemaps in order to do relative URLs.
   This is a big win in my setup since I include imagemap menus at the
   bottom of nearly every page.

   I accomplished this by relying on the Referer: header even after
   RST's caution.  Perhaps someone can figure out how to get this
   info in a more dependable fashion. I can't. :-)

Hmmm... might as well say what my concern was.

To clarify what's going on here --- if there are relative URLs in the
imagemap, they will be interpreted relative to the URL given as
"Referer:" by the client, which will (generally) be the URL of the
document containing the imagemap.

My concerns were that Referer: might get garbled by some browsers
under some circumstances (e.g., if imagemap URLs wound up on someone's
hotlist, the Referer might not be remembered or sent), and that if the
imagemap itself were included, or if it was the result of some sort of
internal redirect from a CGI script, then having the result be
relative to the URL which the client originally submitted might not
fit the principle of least astonishment.

In a sense, there's an empirical issue here; either Randy will wind up
getting burned by issues like this, or he won't.  In any case, I'm not
a heavy user of imagemap-based setups, and will bow to the opinions of
people who have more experience with them about whether this the right
way to go.

   BTW - The imap parsing code is nasty and needs some serious cleanup.
   It is not very foolproof at this stage. All in all, I can't wait to
   tackle the next module!  

Another issue with "borrowed" CGI script code is leak safety --- it
doesn't matter if you forget to close a file in a CGI script, but it
can be catastrophic in a module.  It might be good to give the code a
once-over for this sort of thing...

   RST - How do you want to distribute this? Shall I send it to you?

For the moment, yes, what the hey.  However, a proliferation of new
modules does raise the question of how people are going to pick and
choose.  (Of course, we already have that problem, with two modules
--- mod_auth_dbm and mod_dld --- which require libraries that aren't
universally available, but it'll only get worse).  Maybe we need a
snazzy config script to generate the modules.c file (which contains
the list of modules linked with the server) and the Makefile line
which lists the modules to compile and link...

rst







Mime
View raw message