The cookie is a token that can be used by the handler to look up information
about this particular instance. For example, it could be a handle to a
data structure describing this mount point. This allows a handler to
mounted in more than one place, yet still have a handle to mount point
specific information.
For example, the ismap handler can read in map information when the
process starts up, and use the cookie to find the table when a request comes
in.
> @ 'url' is the URL that is being processed. This url should have any leading
> @ protocol specifiers removed before the handler is called.
>
> Wouldnt this be better as a "URI" rather that the URL. Hrm, actually
> isnt a URI a URL with all the "leading protocol specifiers removed" so
> to speak.
UR* is not a valid C variable name, and John Mallery's already has a lisp
protocol :-)
One change that has been made is that there's now an extra 'version' paramater,
which is an int whose value is the http version multiplied by 100.
> @ occur, the handler should either return -1, indicating that the server should
>
> Shouldnt this always be a valid HTTP code. i.e. if you want a -1 style
> return 500 is good enough?
The -1 indicates than an error occured, but the gateway has already generated
its own error. Since there's a function in the support library to generate
errors I could change it to require the gateway to generate the error, in which
case I'd also change the ok result to 200 as well.
> > @ 1) It might be better to have separate handlers for each method, rather than
> > True, but it would also be easier if new methods are added later. Rather
> than modifying the existing handler you would just add a new one. For
> example to handle HEAD (which is strangely missing in this document I
> feel.)
I've been havvering about this, and I'm going to try implementing the multi
function model as well to see how it work. The hardest part is designing
the configuration file format ;_)
For this approach, the method specific functions would be the same as
before, but without the 'operation' paramater. In addition, a catch-all
method handler would be added, with operation redefined as string.
> One other question. Would this be fork() based HTTPD or would it be
> select() based or better still threaded? Hope this makes some sense.
BGI is neutral with regard to single-thread/multi-thread. Since my daemon
is Multi-threaded, I specified that all handlers must be re-entrant.
Simon