X-Uri:
http://www.zyzzyva.com/ Date: Sun, 02 Jul 1995 12:03:57 -0500
From: Randy Terbush <randy@zyzzyva.com>
Apparently can't be done with the current imagemap program. The
behavior I described as a bug in Shambhala exists in 0.6.5 as
well. It looks like imagemap does not grok a map file containing
a URL without leading slash.
Correct. Known problem, which could be fixed by fixing the imagemap
program. (It would have to take PATH_INFO as the URI of the map
itself, interpreting relative URIs in the map file itself as relative
to that, and concocting the full local URI itself; eminently doable).
This could probably be fixed relatively easy.... As I look at this
it seems that we need a mod_imagemap for Shambhala. Are there some
basics that could be shared with the group regarding the module
interface? How do we currently determine when to run the code
in a module? ie mod_cgi
I really ought to start writing it up... here are the basics:
Shambhala breaks down request handling into a series of steps, more or
less the same way the Netscape Server API does (although Shambhala has
a few more stages than NetSite does, as hooks for stuff I thought
might be useful in the future). These are:
*) URI -> Filename translation
*) Auth ID checking [is the user who they say they are?]
*) Auth access checking [is the user authorized *here*?]
*) Access checking other than auth
*) Determining MIME type of the object requested
*) "Fixups" --- there aren't any of these yet, but the phase is
intended as a hook for stuff like SetEnv and the like, which don't
really fit well elsewhere.
*) Actually sending stuff back to the client. [.This is a special
case; the core code actually does a dispatch on MIME type, though
as of 0.4.5 modules can declare handlers for "*/*", which are
invoked in order of module priority if no handler for the specific
type exists, or if all the type-specific handlers decline to handle
the request --- this is how XBITHACK works].
*) Logging the request
The module structure is actually, for the most part, just a dispatch
table, with one entry for each phase, which is either NULL or a
handler for the phase. The handlers, if they exist, are functions of
one argument (a request_rec structure) which all return 'int' --- the
integer they return is either OK (i.e., "I handled it"), DECLINED
(in which case the server core acts as if the handler didn't exist for
purposes of this request, and looks for another), or an error code, in
which case the request is aborted, and the ErrorDocument machinery
comes into play.
Additionally, there are two subsidiary dispatch tables in the module
structure, one for config-file commands which the module defines
(details put off to another note), and one for MIME types for which
the module can generate a reponse. (There are also functions which
handle reinitialization at server restart, and which deal with the
module's private config data structures, if it has any).
Response handlers have a few more options than handlers for the other
phases; in addition to declining, or returning an error code (before
sending anything --- we don't want two HTTP headers in one response!),
they can use send_http_header(), rprintf() and the like to actually
send a response, or they can handle redirects in one of two ways:
*) set "location" in the out_headers of the request_rec, and
then return REDIRECT (which is how extrenal redirects are
handled).
*) invoke the function "internal_redirect" with some local URI,
and then return OK (which is how internal redirects, e.g., to
DirectoryIndex files, or from CGI scripts, are handled, as well
as how ErrorDocument works internally).
These last options are presumably what the response handler in an
imagemap module would do in the typical case.
That's still too sketchy, but it should help you find your bearings, I
hope.
I would probably quickly be over my head with mod_imagemap, so I
think I will give the mod_logpipe a try first.
OK --- the tricky part is making sure that it cleans up after itself
on server restart, i.e., at the time that the config resource pool is
cleared. One of my TODO list items is to make it possible for you to
do this using your own cleanup function; this would make it possible
for you to just use popen(), registering the pclose() as a cleanup on
the config resource pool. That'll hopefully be done this
weekend.
FWIW, alloc.c does provide a spawn_child routine which arranges for
pipes either into or out of the child process (there are FILE **
arguments which are either NULL if you don't want to pipe data in that
direction, or get set to FILE *s which have the right end of the pipe
if you do), and arranges for the SIGTERM/pause/SIGKILL routine to
ditch the process when the relevant resource pool is cleared. If you
want to try using this, the best code to copy here would probably be
the code that handles <!--#exec cmd="..."--> directives (the function
include_cmd in mod_include.c), though you'll want to set up to pipe
into the process, rather than out of it, meaning the last two
arguments to spawn_child will be different.
(If you use spawn_child, then the child will still receive a SIGHUP as
the root server process blows away all its server children, before the
SIGTERM/pause/SIGKILL routine; if this isn't desirable, just ignoring
SIGHUP before the exec() should shield your child from it. If you use
popen(), once the general cleanup interface is there, then you still
get the SIGHUP, but after that you get whatever behavior pclose()
gives you --- which may mean waiting indefinitely if the child refuses
to die).
I hope this isn't all too obscure, but expect otherwise. (Sigh...).
Let me know what needs to be expanded on...
rst
