httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From d...@ast.cam.ac.uk (David Robinson)
Subject Re: ISAPI "standard"
Date Tue, 12 Dec 1995 18:11:00 GMT
>At the basic level, ISAPI doesn't offer much beyond what CGI already 
>offers, but does so without forking an extra process.  Essentially, you 
>have a DLL which is your ISAPI application.  This DLL is required to have 
>two entry points GetExtensionVersion() and HttpExtensionProc().  
>GetExtensionVersion() makes sure that your server and ISAPI app's version 
>line up.  HttpExtensionProc is analagous the 'main' of the cgi script.  
>HttpExtensionProc is passed an EXTENSION_CONTROL_BLOCK structure which 
>contains information for most of the CGI environment variables and those 
>that aren't included can be accessed with a server callback 
>GetServerVariable().  There's another server callback, 
>ServerSupportFunction() which lets you do things like send redirections 
>and such.  So, that's all of ISAPI.  ISAPI app's are then invoked as 
>http://servername/foo.dll

How do you read/write the request/response?

This sounds very much like what I had thought about for a simplified
'file handler' interface, i.e. a cut down module API for those modules
which only handle a file, and don't require config directives, or do
logging etc. 

It should be quite easy using dlopen() etc on those machines that support this.
(Solaris 2 and SunOS 4, at least.) _However_, I haven't looked to see
whether the shared library can call server routines by symbol name;
I have this suspicion that the server will have to pass pointers to
any useful routines that the library might want to call.

Recently I was thinking that this could, in fact, be CGI/1.1 compatible.


 David.

Mime
View raw message