Re: Binary Gateway Inferface - An API for extensible HTTP servers

Simon E Spero <ses@tipper.oit.unc.edu>
Errors-To: listmaster@www0.cern.ch
Date: Thu, 23 Jun 1994 20:04:41 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <9406231225.AA03490@tipper.oit.unc.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: ses@tipper.oit.unc.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Simon E Spero <ses@tipper.oit.unc.edu>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Binary Gateway Inferface - An API for extensible HTTP servers 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas


> @ 'cookie' is the token returned by the initialisation function.
> Can someone explain why this is needed?

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