Design Considerations for the Apache Server API

The Apache web server[1] is a high-performance freeware server, which offers a high degree of drop-in compatibility with the popular NCSA server[2]. Internally, the server is built around an API (application programmer interface) which allows third-party programmers to add new server functionality. Indeed, most of the server's visible features (logging, authentication, access control, CGI, and so forth) are implemented as one or serveral modules, using the same extension API available to third parties. The purpose of this paper is not so much to describe the API in detail, as to explain some of the design decisions which went into it, and why things are done the way they are. In order to do this, it explains what problems the API tries to solve, and how it is structured to solve those problems. It also compares and contrasts the approach taken in Apache to the approaches taken to similar problems in other web servers, and reflects a bit on some features, or misfeatures, which, in the view of the author (who was largely responsible for it), might in retrospect have been done better — including features supported by other servers but not by Apache (yet).