A simple web server delivers static documents which are stored on the server as files. The author has to change or update these documents manually. As the Internet and also the demand for high-level multimedia content grew, the need for dynamic web pages arose. Web based applications ranging from a personal address book to online banking applications or a big portal that allows personalization can either be achieved by altering the server's functionality, via server-side or client-side scripting. As this document is focused on the Apache Web Server, client-side scripting like Java Script will not be covered.
Basically, web clients are designed to display pages that they received as reply to a request. The server can therefore either send a static file or generate a page based on data from external sources like a database and/or on data received by the client. The client sends data of HTML Forms with GET or POST requests or via proprietary ways implemented in Java Applets.
The first technology that was available to offer dynamic web content was CGI (Common Gateway Interface). CGI enables the web server to execute external programs,which output HTML code.
Alternatively, extending the functionality of Apache to implement dynamic Web Applications would include the need to develop additional modules, which is covered later in this document. Writing a separate module for each web application allows for good performance, but can be rather complicated and expensive. As each new module would either need a server restart or even a complete recompilation of the server source code, that solution is rather inconvenient, especially in ISP environments where multiple parties share one server.
Therefore most web applications are usually implemented using a scripting language which will be executed by a interpreter called via CGI or by an interpreter module.
An easy way to enable a server to deliver dynamic content is to employ server-side scripting. As mentioned above one of the first technologies to enable the server to provide dynamic content was CGI(G). To enable scripting using CGI, the web server executes an external program, which is able to interpret scripts that return HTML code to the server which then forwards the output to the client.
Optionally the server is enhanced using modules to support script languages that are interpreted within the server's context when a request is handled. The module supplies an execution environment for the script and offers API functions to enable the script to access external data sources and data received from the client.
In Apache, each script-language-enabling module usually registers a separate MIME-type and defines a file extension for files supposed to be executed by the module's content handler.
Generally Server-side Scripting can be subdivided in scripts embedded in HTML files and scripts that output complete HTML documents.
In this case the script is embedded in the HTML document file on the web server. Basically the document includes HTML code like a static page. Within certain tags that are recognized by the script-executing module, the developer can insert scripting instructions that will output HTML code replacing the scripting instructions. The output these instructions generate can be based on external data sources such as a database or on input received by the client with the request.
One example for scripting embedded in HTML code is "Server Side Includes" also referred to as SSI. SSI enables basic commands like assigning values to variables, accessing own and system's variables, doing basic computation and even execute system commands like on a command line and printing their output to the web page.
One common use for SSI is to include another file into a document. Therefore SSI can be used to decorate CGI pages with a header and footer and therefore save some work when programming CGI pages by excluding static HTML output from the CGI script. (See below for information on CGI).
SSI commands can be included in HTML pages using special commands within comment tags, which a browser will ignore in case the server is accidentally unable to interpret the script:
For complex web applications HTML enriching script languages tend to be not performant enough. Therefore compiled programs or scripts are used that output complete HTML documents. Files containing scripting commands may not include static HTML, which relieves the server from having to parse the whole document for scripting instructions. Another reason for these script languages to be a lot faster than languages allowing simple HTML code in their files is that some of them can be compiled and therefore run a lot faster than scripts that have to be interpreted.
Examples for that category are CGI programs and Java Servlets. Certain flavours of CGI and Java Servlets have to be compiled and therefore gain performance.
Usually such technologies are a lot more powerful and therefore allow for more flexibility. Communication with external programs is easier and some even start processes that run in the background and are responsible for keeping state information. CGI is used to start external programs (like directory info, e.g. ls -l or dir) and send their output to the client. The drawback of CGI's approach is the fact that the program is started in a separate context (e.g. a process) when a request is received which can drastically affect performance. Additionally communication is restricted to the use of environment variables and the use of STDIN and STDOUT.
Scripting technologies employing modules to interpret scripts overcome these limitations as scripts are interpreted in the server context. Therefore no context switch is needed and communication between server and script is only limited by the server's and the module's API. With that technology, a request arriving at the web server will trigger the execution or interpretation of the script and forward all output to the client. Therefore the script outputs HTML code, which is sent to the client and interpreted by the client's browser as if it was a static HTML page.
The complexity of a script application is usually not limited by the script language capability but by the servers performance. For very complex applications it might be worth implementing an add-on module compiled into the web server and therefore usually gains performance as no interpretation nor a context switch is needed Additionally the possibility to use the complete server API without the restrictions a interpreting module may imply allows for more powerful applications.
 |
Apache Modeling Portal 2004-10-29 |