Oracle WebServer User's Guide
Oracle Web Listener Features
The Oracle Web Listener includes a number of features to enhance performance and extend its usability in a variety of environments.
High Performance Architecture
For maximum performance the Web Listener is designed to run as an asynchronous engine via a single process with a single thread, in comparison to most HTTP servers, which start a new thread or process whenever a new connection is made. This considerably decreases the time required to service a request and reduces Listener machine resource utilization, providing high performance under a heavy load.
File Caching in Memory
The Oracle Web Listener allows a configurable set of commonly accessed files to be cached in memory. This provides very good performance when these files are accessed by a client.
In the current version of the Oracle Web Listener, the list of files to be cached in memory is determined by the WebServer Administrator and configured manually. The administrator should periodically analyze the Listener logs to determine which files should be cached and to change the configuration accordingly.
Memory Mapping of Files
On operating systems which support this feature, the Oracle Web Listener will automatically map files into memory addresses when they are accessed ( unless it is otherwise specified that they are to be cached permanently into memory),. In this case the file will appear to be loaded in memory, allowing more than one connection accessing the same file to avoid duplicate disk reads. In addition, the operating system will usually pre-fetch the next segment of a memory-mapped file while the previous one is being transmitted, further increasing performance, even in the single connection case.
Directory Mapping
The Oracle Web Listener supports mapping pathnames that appear externally in URLs on the Web to locations internally on the Web Listener machine. This allows a consistent appearance to the clients, even if the Web Listener's disk is reorganized.
The specific mapping of externally visible (virtual) directories to local physical directories in the file system is configurable by the WebServer Administrator.
For example, the URL
http://www.acme.com/products/info.html
can be mapped into the directory /disk1/ products of system www.oracle.com as:
/disk1/products/info.html
If the products directory is moved to /disk3 in a reorganization, the Administrator reconfigures the virtual directory products to point to the new location /disk3/products in the Web Listener configuration file (owl.cfg), and the Web client is completely unaware of the change.
For a full description of the use of directory mappings to control the use of "virtual" parent directories and subdirectories, see the section "Directory Mappings" in Chapter 7, "The Oracle WebServer Administration Utility".
Note: The Web Listener needs to be reloaded to recognize the change. For information on reloading the Web Listener, see "Web Listener Control Utility" later in this chapter.
Language Extensions
The Oracle Web Listener supports files stored in different character sets appropriate to the language being used. The Web Listener can interpret the file extension to provide both the type of the data in the file (such as HTML data) and the national language in which the file is written. The language mapping feature is controlled by the Administrator, and allows files written in different character sets appropriate to national languages to be accessed by clients of the Web Listener.
The mapping of specific file extensions to language and data types is controlled by the Web Listener configuration file.
For more information about the Web Listener configuration file, see "Configuration Parameters," later in this chapter.
HTTP Protocol Negotiation Features
One of the features of HTTP is the ability of clients and HTTP servers to exchange information about the types of data they can transfer and interpret. These negotiation features allow the construction of systems composed of different data types and languages.
When a Web client requests an object, it can specify what types of data it can receive and express a preference for specific types. The Web Listener can use the information to send the appropriately formatted data to the client if more than one format is stored on the Web Listener. This process is called HTTP type negotiation and is fully supported by the Oracle Web Listener. For example, a document might contain an inline image, which could be transferred in either GIF or JPEG format to a Web client.
The Oracle Web Listener also supports a similar concept for negotiation of the appropriate national language to display a document for a specific user. The document could be stored in multiple national languages (for instance English and Canadian French), and the appropriate copy of the document would be sent if the client expressed a preference. This makes the maintenance of a multilingual Web site a great deal easier, since there is no need to maintain duplicate URLs and separate directory trees for different languages.
Common Gateway Interface (CGI)
Common Gateway Interface (CGI) version 1.1 is the standard technique used by an HTTP server to execute a program that generates HTML output. This technique provides dynamic content rather than static content from files on disk. The Oracle Web Listener is fully compliant with CGI 1.1.
When a request comes in that the Web Listener recognizes as a request to execute a CGI application, a separate process is created to perform the operation. The Web Listener maintains communication with the process to transmit input from the Web client to it, and to retrieve the HTML output it may generate for display on the client's screen.
The Web Listener Administrator can configure specific directories to contain CGI applications to be run instead of files to be transmitted. Either of these can be done using the Web Listener configuration file. For more information on the Web Listener configuration file, see "Configuration Parameters," later in this chapter.
When a client requests a URL from the Oracle Web Listener, the URL's pathname component is analyzed to determine if it represents a directory containing files (the usual case). These files are then sent immediately to the client or to a directory containing CGI applications, sometimes referred to as scripts, which must be executed as separate programs to generate output which is then sent to the client.
The technique of CGI application execution is one of the key features of the Web. It allows the integration of many information sources. The Oracle Web Agent is one CGI application that can be accessed using this technique.
Once the Listener has determined that a URL represents a CGI application, it interprets the URL to extract path information and arguments to be passed to the CGI application on startup.
URLs to CGI programs are split into three different parts:
The syntax is as follows:
virtual_path extra_path_information?query_string
| virtual path | similar to a path you would use to access a regular document or image. That is, it points the server to the file that contains the CGI program you want executed. |
| extra path information | additional information you can embed in the URL after the program name. Extra path information is optional. It can be used to convey constant information to your scripts independent of the client's intervention. It can also be used to access the server's virtual-to-physical path translation mechanism. |
| query string | another optional part of the URL. It can either be explicitly given in the hypertext anchor, it can come from a user typing into a search dialog box for an HTML document with the ISINDEX tag, or it can come from HTML forms. |
User input from URLs and other resources
When data is typed into a search dialog or text entry form, the data is encoded using URL encoding. In this encoding the following rules apply:
- Spaces are changed into + signs
- Any of the characters can be "escaped" by changing them into a sequence of the form %xx, where x is a hexadecimal digit. The character is identified by translating the two hexadecimal digits into a number from 0-255, which represents a character.
If the data is coming from a search dialog resulting from an ISINDEX tag, the above translations can be applied directly. Further, your CGI program can receive this information fully translated on the command line if you want to avoid performing the translation yourself.
If the data is coming from an HTML form, then the location of this data varies depending on the method attribute specified with the FORM tag in your HTML document. If the GET method is used, this information comes from a QUERY_STRING variable. If the POST method is used, this information is sent to your program using standard input.
The data provided will be in the form:
name1=value1&name2=value2.....&nameN=valueN
If there are any equal signs (=) or ampersands (&) in the encoded data, they are encoded using the above encoding rules. To decode the data appropriately, the NAME=VALUE pairs should be split (eliminating the ampersands), then each pair should be split into a name and a value, and then the URL decoding should be applied to each portion of the pair.
When a form is submitted you can often use the order in which the form items appear to determine the order in which your CGI program receives the NAME=VALUE pairs. However, you should not depend on this behavior. The various form elements have their own ways to determine what value will be associated with the name they are given. All of the textual input areas use the user's typed input as the value.
- Radio buttons use the value of the enabled button.
- Checkboxes are unchecked. Hence, they will use either an empty string, or their name will not appear in the encoded form data at all.
- Hidden form elements can be used to send constant or state information to your script.
Imagemap Support
The imagemap feature of the Oracle Web Listener allows a displayed image sent to the client to have multiple link areas that provide different hypermedia links (URLs) based on where the user clicks on the image. An example is a map of the world that allows the user to select a country by clicking on it. Use of imagemaps is extremely common in sophisticated Web sites.
The Oracle Web Listener includes native processing of imagemaps within the Web Listener. Many other HTTP servers require a separate process to be created to interpret an imagemap. By doing this internally, the Oracle Web Listener improves performance and lowers system resource utilization when this common feature of HTML is being used.
Domain Name Server (DNS) Resolution
When a client requests a URL from an HTTP server, the client's network address (IP address) is logged by the HTTP server and can be used to control access to documents on the HTTP server. The Domain Name System (DNS) converts the client's network address to the client's hostname as an ASCII string.
Note: The DNS process can be time consuming, since another machine where the naming system is already running may be contacted.
The Oracle Web Listener provides three options for controlling DNS resolution of network addresses:
- Always resolve addresses on connections.
- Do "lazy" resolutions where the name is not resolved until an external application, a security module, or a CGI script needs it.
- Never resolve addresses even if a client asks for it.
You can use the Oracle WebServer Administration Utility or edit the configuration file to control which type of DNS resolution is used. The default is never to resolve using DNS, which provides the best performance.
When DNS resolution does occur, the results are cached. Since there are often several connections from the same client in close succession, this helps to minimize the performance penalty if DNS resolution is required.
Client to Web Listener Security
The security framework for the Oracle Web Listener includes support for Basic Authentication and Digest Authentication. Both of these schemes provide for username and password authentication on documents. Access may also be controlled based on the client's network address. Use the Oracle WebServer Administration Utility, described![[*]](jump.gif)
, to configure the security features.
This scheme uses usernames and passwords which are sent in the clear across the network. This technique has largely been replaced in practice by Digest Authentication and is included for compatibility with older Web browsers that don't implement Digest authentication.
This scheme is similar to Basic Authentication, except that it uses usernames and passwords which are sent encrypted across the network. A cryptographic checksum (digest) is used to encode the password, preventing an attacker from gaining access to the original username/password combination. This technique is significantly more secure than Basic Authentication and is recommended for all new applications, although older browsers, some of which are still quite popular, do not support Digest Authentication.
The network address of the client may be used to restrict access to information on the Oracle Web Listener. Addresses may be individually restricted or allowed access, or entire IP networks may be specified to allow users within certain locations access while denying all others.
When a client requests a file protected by IP-based security, its address is compared against the specified addresses in the order given, and as soon as a match is found, the client is allowed or denied access as specified. Files protected by IP-based restriction may not be accessed by clients other than those listed in the configuration parameters.
Note that Digest Authentication is a safer technique to determine who a user really is, since a credential (the password) must be presented to gain access. Network address-based restriction techniques are very convenient in that they avoid password management problems, but are also less secure, since a clever attacker may falsify network addresses.
Domain name-based restriction is similar to IP-based restriction. A list of groups and hostnames specifies which hosts should or should not have access to a set of documents.
This technique uses symbolic hostnames rather than network addresses. Hence, it is easier to administer since network addresses may change if the network architecture is changed. This technique still suffers from the problem of clever attackers falsifying their network addresses and assuming the identity of a host other than their own.
Security on Specific Files
Specific files can be made secure by associating them with Basic Authentication, Digest Authentication, IP-based restriction, domain-name based restriction, or any combination of one authentication and one restriction method.
Other Security Features
In addition to the authentication features, the Web Listener's user and group ID (on UNIX implementations) may be specified in the configuration file so that the Web Listener itself can be restricted to accessing only files available to that user and group. This allows the Web Listener to be started as a privileged user as required on some implementations, but still operates as if it were an unprivileged program. This provides additional security against an attack directly on the Web Listener process. For more information on the use of the Group ID for security purposes, see "Basic Configuration Parameters" in Chapter 7 of this document.
Logging
When a request is made of the Web Listener, the request information may be logged to a specified log file. The Oracle Web Listener records connections in the industry standard Common Log Format. This format includes the first line of the client's request, which specifies the action, URL, and protocol version. It also includes such information as the client's host address, whether the request was successful, and how many bytes were transmitted. This information may be later used to analyze what types of accesses are performed by which users, and to check for errors. Use the WebServer Administration Utility to specify the log file directory and the names of the standard and error log files in the Web Listener configuration file.
Note: Be sure that the user ID under which the Web Listener runs has privileges to read and write to the log file directory.
Starting Up and Shutting Down the Oracle Web Listener
The easiest way to start up, shut down, or reload an Oracle Web Listener is to use the Administration Utility described of this document. If you wish to perform these operations from the UNIX operating system, use the WLCTL Utility as described in the next section.
The WLCTL (Web Listener Control) Utility
This utility resides in the ORACLE_HOME bin directory and allows you to easily startup, stop, and reload your Oracle Web Listener.
The syntax you use to invoke WLCTL to perform various operations is as follows:
> wlctl [start|stop|reload] [port_number] ORACLE_HOME
If ORACLE_HOME is set in your environment and is the ORACLE_HOME where the Oracle WebServer is installed, it need not be included on the command line.
The following examples assume that the Oracle WebServer is located in /u01/oracle:
>wlctl start 8888
- Specifying ORACLE_HOME on the command line:
>wlctl start 8888 /u01/oracle
wlctl stop 8888
- Specifying ORACLE_HOME on the command line:
wlctl stop 8888 /u01/oracle
>wlctl reload 8888
- Specifying ORACLE_HOME on the command line:
>wlctl reload 8888 /u01/oracle
The stop and reload functions require that the Listener PID file for the Web Listener you are stopping or reloading resides in the location pointed to by the Web Listener configuration file.