My philosophy: we need to have the simplest possible interface. This
makes it easy to use, and also makes a mod_unicon module portable
between various HTTP servers. Function names and the filename
are fully defined by naming the module - no need for string
translation tables etc. to set up.
Here's a proposal for what mod_unicon code might look like:
Name of module used in this example: artemis
Four procedures can be defined in the module: artemis_init(),
artemis_path_xlate(), artemis_handler(), artemis_cleanup()
There are only two callbacks: one to translate the URI to a path on
the filesystem, and then to handle the request itself. These are
separated because the web server may have a number of path xlation
routines that might need to run. [Open for debate - maybe we only need
one handler.]
0. Initialisation
The web server's config file has a directive to load a Unicon module:
Apache:
UniconModule "artemis"
Netscape:
Init fn="load-modules" shlib=".../iconx.so" funcs="mod-unicon-init"
Init fn="mod-unicon-init" module="artemis"
Initialise iconx; look for file artemis.u. If the procedure
artemis_init() exists, it is called.
1. Path translation
Translate the URI ("/some/long/path/foo.gif") into a path on the
filesystem
procedure artemis_path_xlate(uri, headers)
# In some cases, we don't know how to xlate the URI; if we
# fail, any other components of the web server that can do it
# will be called.
if ... then fail
# "headers" is a table that maps names of HTTP headers to values
root := modunicon_docroot()
path := root || ...
return path;
end
2. Serve the request
Given the URI, the translated path and request headers, return data
procedure artemis_handler(uri, ppath, headers)
# Failure => we decline to serve this request; the server
# should try other request handlers it has
# Integer => HTTP status codes.
if (...) then {
# We have some custom "not found" HTML in the string html_notfound
headers["content-length"] := *html_notfound
modunicon_sendheaders() # mod_unicon will fill in other hdrs
write(html_notfound)
modunicon_log(UNICON_INFO, "...")
return HTTP_NOT_FOUND
}
# Handling POST data
if headers["Method"] == "POST" then {
modunicon_readtimeout(30)
l := headers["content-length"]
d := ""
while s := reads(l) {
# POST data is in &input. If the timeout trips, read/reads
# will return EOF
d +:= s
if *d >= l then break
}
}
modunicon_hoheaders() # we will send all headers ourselves
write("Content-length: ", ...)
write("Content-type: ", ...)
write(... other headers...)
write()
# If we just want to serve up a file
modunicon_sendfile(f) # f can be a filename or open file
# Or we can write HTML or whatever directly
write(...)
return HTTP_OK
end
3. Cleanup - whatever we need.
There are some things that you might think should be in the parameter
lists for the callback procedures; we define addition "pseudo-headers"
that have those values, and will be passed in in the "headers"
table. These are things like connection details: request type (GET,
POST, etc.), IP number of remote host, identd reply if any etc. The
same table is used to set headers in the returned document.
More things we need to figure out: establishing the call order for
various modules; need for multithreading (NS is multi-threaded, and
Apache 2.0 will be) and feasibility in Unicon; do we need another
phase (i.e. callback) for HTTP auth or can we do that with pseudo-
headers... an any others.
What do you guys think?
-s
_______________________________________________
Unicon-group mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/unicon-group
