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:
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.
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.
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. OmniHTTPd supports ISAPI extensions only. ISAPI filter support is not likely for future releases. Most ISAPI applications come in the form of ISAPI extensions.
Similar to ISAPI except developed by Netscape. As this time, only Netscape's servers support NSAPI. OmniHTTPd does not support NSAPI.
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.
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.
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.