Overview
A plain HTML document that the Web daemon retrieves
is static, which means it exists in a constant
state: a text file that doesn't change. A Web
extension on the other hand, is executed in
real-time, so that it can output dynamic
information.
For example, let's say that you wanted to
"hook up" your database to the World Wide
Web, to allow people from all over the world to query
it. Basically, you need to create a Web extension
that the Web server will execute to transmit
information to the database engine, and receive the
results back again and display them to the client. If
the information in the database changes, they will be
reflected in the information sent back to the client.
The database example is a simple idea, but most of
the time rather difficult to implement. There really
is no limit as to what you can hook up to the Web.
The only thing you need to remember is that whatever
your Web extension does, it should not take too long
to process. Otherwise, the user will just be staring
at their browser waiting for something to happen.
Note that Java, Javascript, VBScript, Dynamic HTML
and ActiveX are not considered Web extensions because
their processing is done in client's browser. As a
result, these technologies are independent of the
server and are not discussed here. By design, all Web
servers, including OmniHTTPd, support these
technologies.
There are several methods for interfacing a Web
extension with a Web server. For the developer, the
choice of interface depends on complexity,
performance and portability. Each of these are
discussed below:
Standard Common Gateway Interface (CGI)
The Common Gateway Interface (CGI) is a standard
for interfacing external applications with Web
servers. It the earliest interface and is universally
supported by all Web servers. Extensions using CGI
are usually called CGI programs or CGI scripts.
OmniHTTPd supports Standard CGI.
Windows Common Gateway Interface (WinCGI)
The Windows Common Gateway Interface was developed
by O'Reilly in an effort to simplify script code. As
the name implies, it is designed primarily for the
Windows environment. Not all Windows Web servers,
however, support Windows CGI. OmniHTTPd supports
Windows CGI.
Internet Server Application Programming
Interface (ISAPI)
The ISAPI extension interface was developed by
Microsoft in an effort to speed up the execution of
scripts in the Win32 environment. Support for ISAPI
is limited to a few Web servers, including
Microsoft's Internet Information Server. ISAPI filter support
is planned for future releases. OmniHTTPd currently
supports ISAPI extensions only. Most ISAPI applications
come in the form of ISAPI extensions.
Netscape Server Application Programming
Interface (NSAPI)
Similar to ISAPI except developed by Netscape. As
this time, only Netscape's servers support NSAPI.
OmniHTTPd does not support NSAPI and future support
is not likely.
Java Servlets
Java Servlets are an attempt by Sun Microsystems
to encourage the use of Java for server-side
processing. OmniHTTPd does not currently support Java
Servlets. Future plans for support are contingent on
receiving proper permission to use the OS Java
Virtual Machine.
Server Side Includes (SSI)
Although Server Side Includes are not a type of
external interface, they can provide similar
functionality by allowing the insertion of dynamic
data into web pages before they are sent back to the
client. OmniHTTPd support SSI.
Active Server Page (ASP)
Another type of dynamic insertion process designed
by Microsoft. ASP was meant to provide an open
architecture for a variety of script languages for
server-side processing. Although OmniHTTPd does not
have native support for ASP, users can install
ChiliASP by ChiliSoft, which uses ISAPI to provide
seamless ASP support for ISAPI-compliant web servers
like OmniHTTPd.