Document revision date: 28 June 1999

This chapter describes the access-control list (ACL) files and their syntax. ACL files are text files that contain lists that define who can access resources stored on your web server. By default, the web server uses one ACL file that contains all of the lists for access to your server. However, you can create multiple ACL files and reference them in the obj.conf file.

You need to know the syntax and function of ACL files if you plan on customizing access control using the access-control API. For example, you might use the access control API to interface with a database, such as an Oracle or Informix database. For more information on the API, see the DevEdge site at:

http://developer.netscape.com/library/documentation/index.html

6.1 ACL file syntax

All ACL files must follow a specific format and syntax. An ACL file is a text file containing one or more ACLs. All ACL files must begin with the version number they use. There can be only one version line and it can appear after any comment lines. For example:

version 3.01;

You can include comments in the file by beginning the comment line with the # sign.

Each ACL in the file begins with a statement that defines its type. ACLs can follow one of three types:

• Path ACLs specify an absolute path to the resource they affect.
• URI (Uniform Resource Indicator) ACLs specify a directory or file relative to the server's document root.
• Named ACLs specify a name that is referenced in resources in the obj.conf file. The server comes with a "default" named resource that allows read access to anyone and write access to users in the local database or LDAP directory. Even though you can create a named ACL from the Server Manager forms, you must manually reference the named ACLs with resources in the obj.conf file.

The type line begins with the letters acl and then includes the type information in double-quotation marks followed by a semicolon. Each type information for all ACLs must be a unique name--even among different ACL files. The following lines are examples of several different types of ACLs:

acl "path=/usr/netscape/suitespot/docroot1/sales"; acl "*.html"; acl "default"; acl "uri=/mydocs/";

After you define the type of ACL, you can have one or more statements that define the method used with the ACL (authentication statements) and the people and computers who are allowed or denied access (authorization statements). The following sections describe the syntax for these statements.

6.1.1 Authentication statements

ACLs can optionally specify the authentication method the server must use when processing the ACL. There are two general methods:

• Basic requires users to enter a user name and password before accessing a resource.
• SSL requires the user to have a client certificate. For this method to work, the web server must have encryption turned on.

By default, the server uses the Basic method for any ACL that doesn't specify a method. You can change the default setting by editing the following line in the magnus.conf file:

Init fn=acl-set-default-method method=SSL

Each authenticate line must specify what list (users, groups or both) the server should use when authenticating users. The following authentication statement, which would appear after the ACL type line, specifies basic authentication with users matched to individual users in the database or directory:

authenticate (user) { method = basic; };

The following example uses SSL as the authentication method for users and groups:

authenticate (user, group) { method = ssl; };

authenticate (user) allow (all) user = sales*

If the last line was changed to group = sales, then the ACL would fail because there are no groups in the user lists.

6.1.2 Authorization statements

Each ACL entry can include one or more authorization statements. Authorization statements specify who is allowed or denied access to a server resource. Use the following syntax when writing authorization statements:

allow | deny [absolute] (right[,right...]) attribute qualifier expression;

Start each line with either allow or deny. It's usually a good idea to deny access to everyone in the first rule and then specifically allow access for users, groups, or computers in subsequent rules. This is because of the hierarchy of rules. That is, if you allow anyone access to a directory called /my_stuff, and then you have a subdirectory /my_stuff/personal that allows access to a few users, the access control on the subdirectory won't work because anyone allowed access to the /my_stuff directory will also be allowed access to the /my_stuff/personal directory. To prevent this, create a rule for the subdirectory that first denies access to anyone and then allows it for the few users who need access.

However, in some cases if you set the default ACL to deny access to everyone, then your other ACL rules don't need a "deny all" rule.

The following line denies access to everyone:

deny (all) user = "anyone";

6.1.2.1 Hierarchy of authorization statements

ACLs have a hierarchy that depends on the resource. For example, if the server receives a request for the document (URI) /my_stuff/web/presentation.html, the server first looks for an ACL that matches the file type or any other wildcard pattern that matches the request, then it looks for one on the directory, and finally it looks for an ACL on the URI. If there are multiple ACLs that match, the server uses the last statement that matches. However, if you use an absolute statement, then the server stops looking for other matches and uses the ACL containing the absolute statement. If you have two absolute statements for the same resource, the server uses the first one in the file and stops looking for other resources that match.

For example, using the ACL hierarchy with the request for the document /my_stuff/web/presentation.html, you could have an absolute ACL that restricts access to the file type *.html. Then the server would use that ACL instead of looking for one that matches the URI or the path.

version 3.01; acl "default"; authenticate (user,group) { prompt="Enterprise Server"; }; allow (read,execute,list,info) user = "anyone"; allow (write,delete) user = "all"; acl "*.html"; deny absolute (all) user = "anyone"; acl "uri=/my_stuff/web/presentation.html"; deny (all) user = "anyone"; allow (all) user = "anyone";

6.1.2.2 Attribute qualifier expressions

Attribute qualifier expressions define who is allowed or denied access based on their user name, group name, host name, or IP address. The following lines are examples of allowing access to different people or computers:

• user = "anyone"
• user = "smith*"
• group = "sales"
• dns = "*.netscape.com"
• dns = "*.netscape.com" or "*.mozilla.com"
• ip = "198.*"

ou can also restrict access to your server by time of day (based on the local time on the server) by using the timeofday attribute qualifier. For example, you can use the timeofday attribute qualifier to restrict access to certain users during specific hours.

The following example restricts access to a group of users called guests between 8 a.m. and 4:59 pm.

allow (read) (group="guests") and (timeofday<800 or timeofday>=1700);

You can also restrict access by day of the week. Use the following three-letter abbreviations to specify days of the week: Sun, Mon, Tue, Wed, Thu, Fri, and Sat.

The following statement allows access for users in the premium group any day and any time. Users in the discount group get access all day on weekends and on weekdays anytime except 8am-4:59pm.

allow (read) (group="discount" and dayofweek="Sat,Sun") or (group="discount" and (dayofweek="mon,tue,wed,thu,fri" and (timeofday<0800 or timeofday>=1700))) or (group="premium");

6.1.2.3 Operators for expressions

You can use various operators in attribute qualifier expressions. You can use parentheses to delineate the order of precedence of the operators. With user, group, dns, and ip qualifiers, you can use the following operators:

• and
• or
• = (equals)
• != (not equal to)

With timeofday and dayofweek qualifiers, you can use the following additional operators:

• > greater than
• < less than
• >= greater than or equal to
• <= less than or equal to

After installing the server, the server uses the default settings in the file <server_root>/httpacl/generated.httpd-<serverid>.acl. There is also a file called genwork.httpd-<serverid>.acl that is a working copy the server uses until you save and apply your changes when working with the user interface. When editing the ACL file, you might want to work in the genwork file and then use the Server Manager to save and apply the changes.

The following text is from the default file:

# File automatically written # # You may edit this file by hand # version 3.01; acl "default"; allow (read,execute,list,info) user = "anyone"; allow (write,delete) user = "all";

The default ACL file is referenced in magnus.conf as follows:

ACLFile <absolutepath>/generated.https-<serverid>.acl

You can reference multiple ACL files in magnus.conf and then use their ACLs for resources in obj.conf. However, the server uses only the first ACL file with the web publisher and when evaluating access control for objects that don't have specific ACLs listed in obj.conf. If you're using the Server Manager forms to do some access control, the first ACL file in magnus.conf should point to the file generated.https-<serverid>.acl. See Referencing ACL files in obj.conf for more information.

6.1.4 General syntax items

Input strings can contain the following characters:

• Letters a through z
• Numbers 0 through 9
• Period and underscore

If you use any other characters, you need to use double-quotation marks around the characters.

A single statement can be placed on its own line and terminated with a semicolon. Multiple statements are placed within braces. A list of items must be separated by commas and enclosed in double-quotation marks (see the dayofweek example in "Attribute qualifier expressions" on page 121).

6.2 Referencing ACL files in obj.conf

If you have named ACLs or separate ACL files, you can reference them in the obj.conf file. You do this in the PathCheck directive using the check-acl function. The line has the following syntax:

PathCheck fn="check-acl" acl="<aclname>"

The aclname is a unique name of an ACL as it appears in any ACL file.

For example, you might add the following lines to your obj.conf file if you want to restrict access to a directory using the acl named sample_acl:

<Object ppath="/usr/ns-home/docs/test/*"> PathCheck fn="check-acl" acl="sample_acl" </Object>

In the previous example, the first line is the object that states which server resource you want to restrict access to. The second line is the PathCheck directive that uses the check-acl function to bind the name ACL (sample_acl) to the object in which the directive appears. The sample_acl ACL can appear in any ACL file referenced in magnus.conf.

Netscape servers use an encryption system called Secure Sockets Layer (SSL) to ensure privacy when communicating with other SSL-enabled products, such as Netscape Navigator and Netscape Communicator.

For a complete discussion of encryption and SSL, see the online guide Managing Netscape Servers.

7.1 What is encryption?

Encryption is the process of transforming information so it can't be decrypted or read by anyone except the intended recipient. This encrypted information is called ciphertext. It is the ciphertext that you send across the network. For example, suppose you have a financial report stored at your web site. If SSL is enabled on your server, your server encrypts the report and sends the ciphertext to a client, the client then decrypts the ciphertext back into the financial report.

Decryption reverses the process, turning the ciphertext back into the original message. Only the recipient can decrypt the text because only the recipient has the key. In fact, both the encryption and the decryption processes require keys.

Client-server communication with SSL uses two keys. The encryption key is called the public key, and the decryption key is the private key. SSL uses the two keys as follows:

• A client and server exchange public keys
• The client generates a symmetric encryption key that is used only for this transaction. This key is called a session key
• The client encrypts the session key with the server's public key and sends it to the server
• For the rest of that transaction, the client and server can use the same key for encryption and decryption

There are other security risks besides someone trying to break your encryption. The modern network faces risks from external and internal hackers, using a variety of tactics to gain access to your server and the information on it.

So in addition to enabling SSL on your server, you should take extra security precautions. The following list describes the most important things you can do to make your server more secure. For more information on server security see the online guide Managing Netscape Servers.

• Limit physical access. Keep the server machine in a locked room that only authorized people can enter. This prevents anyone from tampering with the server machine itself.
• Limit administration access. If you plan on remotely configuring your server, be sure to use your administration server's access control to allow administration from a very small number of locations. You should also make the administrative connection a mandatory SSL connection.
• Choose good passwords. It's important to choose passwords that are difficult to guess and never to reveal them to anyone. Your most important passwords should not contain words from any language because numerous password-cracking programs exist that can run through millions of possible word combinations in seconds. Your important passwords also should be at least eight characters long, and contain a mix of uppercase and lowercase letters, punctuation marks, mathematical symbols, or numerals.
• Secure your private key. Make sure your private key file is protected. Store the key file in a directory that only you or authorized administrators have access to. It's also important to know whether the file is stored on backup tapes or is otherwise available for someone to intercept. If so, you must protect your backups as much as you protect your server.
• Limit other applications on the server. It's possible to circumvent your server's security by exploiting holes in other programs running on your server. Therefore, it is wise to disable all unnecessary programs and services. Some applications that you should be cautious of are the sendmail daemon, telnet, rlogin, and rdist. Also be careful about which CGI, Java, and JavaScript programs are on your server.
• Limit ports. Disable extraneous services operating on ports for the machine. Use routers or firewall configurations to prevent incoming connections from accessing services available on different ports.
• Know your server's limits. A server can't control the security of information once it reaches the client, nor can it control which individuals have access to directories and files on the server. Therefore, it is your responsibility to secure any information clients send to you through SSL.

To enable SSL on your server, you must complete these steps:

1. Generate your server's key-pair file (public and private keys). For more information on key pairs, see the online guide Managing Netscape Servers.
2. Request a certificate from a Certification Authority (CA). For more information on Certification Authorities, see the online guide Managing Netscape Servers .
3. Install the certificate the CA sends to you.
4. Activate SSL encryption for your server.

After you have generated a key-pair file and installed your certificate, activate SSL for your server by completing the following:

1. From the Server Manager, choose Server Preferences | Encryption On/Off. The Encryption On/Off form appears.
2. Select the On radio button.
3. Type the port number you want your server to use, if it's different from the one you specified upon setup. Note that the standard port is 443. If you choose another port, clients will have to specify it when they type your URL, as in https://www.mozilla.com:221.
4. From the alias drop-down list, select the name of the alias that you want to use for encryption. This alias maps to the key-pair file and certificate file you associated it with in the administration server.
5. Click OK and then Save and Apply.

Now that SSL is enabled on your server, you can configure your overall SSL preferences. See "Setting encryption preferences" on page 129 for information on configuring encryption preferences for your server.

7.4 Setting encryption preferences

You can set system-wide preferences for SSL, including:

• Specifying the SSL version
• Using client certificates
• Selecting SSL ciphers

You can specify which versions of SSL your server can communicate with. The latest and most secure version is SSL version 3, but many older clients use only SSL version 2. You will probably want to enable your server to use both versions. To specify the SSL version:

1. From the Server Manager, choose Server Preferences | Encryption Preferences.
2. Select SSL version 2, SSL version 3, or both.
3. Click OK and then Save and Apply.

You can configure the web server so that it refuses any client who doesn't have a client certificate from a trusted CA. This differs from access control in that all requests must be through SSL connections and they must be from clients who have certificates from trusted CAs. (See the online guide Managing Netscape Servers for details on configuring trusted CAs.)

With client certificates on, the server asks the client to send its certificate before the server will grant the request. The server doesn't care who the user is as long as that user has a valid certificate from a trusted CA. However, you can combine client certificates with access control so that in addition to being from a trusted CA, the user associated with the certificate must match the access-control rules. See Chapter 5 for more information.

To enable client authentication using trusted certificates:

1. Using the administration server, install a server certificate so that the web server can use SSL encryption, and then trust the CAs whose certificates you want to allow. The server grants requests only to clients that have a certificate from a trusted CA.
2. Enable SSL for the server. See Section 7.3 for more information.
3. From the Server Manager, choose Server Preferences | Encryption Preferences.
4. In the form that appears, choose Yes to require client certificates and then click OK.
5. Turn on SSL for the web server (see Section 7.3. Save and apply your changes, and then restart the server.

If a user accessing the server doesn't have a certificate from a trusted CA, the server returns an error stating, "The server cannot verify your certificate." The server logs an error, but it doesn't list the untrusted CA. If you want to know which CA issued the certificate to the client, you need to use access control in addition to client authentication. With access control and certificate mapping, the server will log an error that lists the CA's distinguished name.

7.4.3 Selecting SSL ciphers

A cipher is an algorithm used in encryption. Some ciphers are more secure, or stronger, than others. Generally speaking, the more bits a cipher uses during encryption, the harder it is to decrypt the data. The list of available ciphers doesn't appear on the Encryption Preferences form unless you've enabled SSL. See Section 7.3 for more information. The Netscape FastTrack Server supports only 40-bit encryption. If you require stronger encryption than that provided by the Netscape FastTrack Server, contact Netscape for information about the Netscape Enterprise Server.

When initiating an SSL connection with a server, a client lets the server know what ciphers it prefers for encrypting information. In any two-way encryption process, both parties must use the same ciphers. Because a number of ciphers are available, your server needs to be able to use the most popular ones.

You can choose ciphers from the SSL 2 protocol, as well as from SSL 3. To specify which ciphers your server can use:

1. From the Server Manager, choose Server Preferences | Encryption Preferences.
2. Check the ciphers you want the server to use. The ciphers are explained in detail below. Unless you have a compelling reason not to use a specific cipher, you should check them all. (One reason for not enabling all ciphers is to prevent SSL connections with less than optimal encryption.) You might not want to check No Encryption, only MD5 message authentication. If no other ciphers are available on the client side, the server will use this, and no encryption will occur.
3. Click OK and then Save and Apply.

The SSL 2.0 ciphers include:

• RC4 cipher with 40-bit encryption and MD5 message authentication. This cipher is also an RC4 cipher, making it one of the fastest available ciphers. It has 40-bit encryption, which has approximately 1.1 * 1012 (a trillion) possible keys. 40-bit encryption is the strongest encryption that Netscape Communications is permitted to export under US law, and is the strongest available with the Netscape FastTrack Server. This cipher also uses MD5 message authentication to detect attempts to modify data in transit.
• RC2 cipher with 40-bit encryption and MD5 message authentication. This cipher is also an RC2 cipher, making it is slower than the RC4 cipher. It also has 40-bit encryption. 40-bit encryption has approximately 1.1
• 1012 (a trillion) possible keys. This cipher also uses MD5 message authentication to detect attempts to modify data in transit.

The SSL 3.0 ciphers include:

• RC4 with 40-bit encryption and MD5 message authentication. This cipher is the same as the SSL 2.0 version of RC4 with 40-bit encryption but uses a more secure implementation of MD5 message authentication to detect attempts to modify data in transit.
• RC2 with 40-bit encryption and MD5 message authentication. This cipher is the same as the SSL 2.0 version of RC2 with 40-bit encryption but uses a more secure implementation of MD5 message authentication to detect attempts to modify data in transit.
• No encryption, only MD5 message authentication. This cipher uses only MD5 message authentication to secure data. Any data sent using this cipher is not encrypted. The data may be protected from modification, but it can be viewed by eavesdroppers.

This section describes what effects you need to know about while running an SSL-enabled server.

7.5.1 Secure URL construction

URLs to an SSL-enabled server are constructed using https instead of simply http. URLs that point to documents on an SSL-enabled server have this format:

https://servername.domain.dom/pathname/unique_file_identifier

7.5.2 Secure server document root

After SSL is installed and enabled on a server, all communications between the server and SSL-enabled browsers (such as Netscape Communicator) are private, authenticated, and checked for message integrity. Thus, any document sent to a user with an SSL-enabled browser is automatically encrypted.

Once SSL is enabled, a new log file, (secure.log) is created in the normal log directory. Entries in the log look like this:

198.93.92.99: [02/Nov/1994:23:51:46 -0800] using keysize 40

The IP address is first, followed by the date and time of access, and then the key size. The key size represents a level of security. Generally, the bigger the key size, the higher the level of security. See Section 7.4.3 for a list of supported key sizes.

Your server still uses the access.log file to log information about server accesses; however, all information regarding secure transactions is logged in secure.log.

7.5.4 Unprotected server document directory

If you want to have both protected and unprotected servers, you should operate the unprotected server on a different machine from the protected one. If your resources are limited and you must run an unprotected server on the same machine as your protected server, do the following:

1. Assign proper port numbers. Make sure that the protected server and the unprotected server are assigned different port numbers. The registered default port numbers are 443 for the protected server and 80 for the unprotected one.
2. Enable the chroot feature for the document root directory. The unprotected server should have references to its document root redirected using the chroot feature.

Installing an SSL-enabled server creates new directive entries in the magnus.conf file (the server's main configuration file). These new directives are briefly described in the following sections.

7.5.5.1 Security

The Security directive tells the server whether SSL is enabled or disabled.

Syntax

Security value

value specifies if SSL is on or off. Set the value parameter to on to enable SSL; and to off to disable SSL.

7.5.5.2 SSL2

The SSL2 directive tells the server whether SSL2 is enabled or disabled.

Syntax

SSL2 value

value specifies whether SSL version 2 is enabled or disabled. Set the value parameter to on to enable SSL 2 and to off to disable SSL 2.

7.5.5.3 SSL3

The SSL3 directive tells the server whether SSL3 is enabled or disabled.

Syntax

SSL3 value

value specifies whether SSL version 3 is enabled or disabled. Set the value parameter to on to enable SSL 3, and to off to disable SSL 3.

7.5.5.4 KeyFile

The KeyFile directive tells the server where the key file is located.

Syntax

KeyFile keyfile

keyfile is the server's key file, specified as an absolute path from the server root.

7.5.5.5 CertFile

The CertFile directive specifies where the certificate file is located.

Syntax

CertFile certfile

certfile is the server's certificate file, specified as an absolute path from the server root.

7.5.5.6 Ciphers

The Ciphers directive specifies the ciphers enabled for your server. For a discussion of these ciphers, refer to Section 7.4.

Syntax

Ciphers +rc4 +rc4export -rc2 -rc2export +idea +des +desede3

A + means the cipher is active, and a - means the cipher is inactive. Any cipher with export as part of its name is not stronger than

7.5.5.7 SSL3Ciphers

The SSL3Ciphers directive specifies which SSL 3 ciphers are enabled for your server. For a discussion of these ciphers, refer to Section 7.4.

Syntax

SSL3Ciphers +rsa_rc4_128_md5 +rsa_3des_sha +rsa_des_sha +rsa_rc4_40_md5 +rsa_rc2_40_md5 -rsa_null_md5

A + means the cipher is active, and a - means the cipher is inactive. Any cipher with 40 as part of its name is 40 bits.

7.5.5.8 SSLClientAuth

The SSLClientAuth directive specifies whether a client must have a certificate in order to communicate with the server. You don't need to turn on this directive to use client authentication with access control.

Syntax

SSLClientAuth value

value specifies if certificates are always required. Set the value parameter to on to require certificates, and to off to specify that certificates are not required.

In addition to serving HTML documents, your server can run programs that interact with clients. These applications that run on the server computer are called server-side applications. (Client-side applications, which are downloaded to the client, run on the client machine.)

Your server can run these types of server-side applications:

• Java applets
• CGI programs
• JavaScript applications
• Plug-in programs that use the server plug-in APIs: Web Application Interface (WAI) and Netscape Server Plug-in (NSAPI)

This chapter describes how to install Java applets, CGI programs, and JavaScript applications onto your server. Plug-ins extend or replace your server's features. For example, you can use plug-ins to provide a different way to control access, or different logging mechanisms.

For information on writing and installing plug-ins, see the DevEdge site at:

http://developer.netscape.com/library/documentation/

Additionally, your server can send these types of client-side applications to clients:

• Java applets
• JavaScript programs

This chapter deals mainly with the installation and configuration of server-side programs, although you'll find some information on client-side applications as well.

Additionally, this chapter describes the steps for specifying a default query handler CGI program. (A query handler processes text sent to it via the ISINDEX tag in an HTML file.)

8.1 Installing server-side programs

Java applets, JavaScript applications, and CGI programs have different strengths and uses. Java is a full-featured programming language for creating network applications. CGI (Common Gateway Interface) programs can be written in C, Perl, or other programming languages; what makes them all CGI programs is the standard way they pass information between clients and servers. JavaScript applications are written in JavaScript, an object-based scripting language; it is easier to learn than an object-oriented programing language and lends itself to rapid application development.

Each type of program is installed onto the server differently. The following list summarizes the procedures:

• For Java applets, copy all your server-side applets into a specified directory and enable your server's Java interpreter.
• For CGI programs, configure your server to recognize certain files as CGI--all files with certain filename extensions, or all files in specified directories.
• For JavaScript applications, check in each application individually through the Application Manager, which you can access from the Server Manager, or separately.

These installation procedures are described in the following sections.

8.1.1 Installing server-side Java applets

Java is a programming language designed for platform-independent application development. If you have a server-side Java applet that works on a Unix server, you can also use it with a server running on Windows NT. Like a CGI program, a server-side Java applet is triggered by a client sending or requesting information in the form of a URL. However, server-side Java applets and client-side Java applets have different formats and are not interchangeable.

To use server-side Java applets with your server, you must enable your server's Java interpreter and copy all Java applets into a specified directory. All server-side Java applet files must be named in the standard format name.class. For more information on creating Java applets that work with your server, refer to Netscape's DevEdge online documentation web site at:

http://developer.netscape.com/library/documentation/

To enable your server to use server-side Java applets:

1. From the Server Manager, choose Programs | Java. The Java form appears.
2. Select the Yes radio button to enable the Java interpreter.
3. Specify a Java applet directory by typing the absolute path to it in the Java applet directory field.
4. Click OK and then Save and Apply.

Be sure to copy all server-side Java applets into the directory you specified.

8.1.2 Installing CGI programs

Common Gateway Interface, or CGI, programs can be created with any number of programming languages. On a Unix machine, you're likely to find CGI programs written as Bourne shell or Perl scripts. On a Windows computer, you might find CGI programs written in C++ or batch files.

Regardless of the programming language, all CGI programs accept and return data in the same manner, as described in Netscape's DevEdge online documentation web site at:

http://developer.netscape.com/library/documentation/

There are two ways to store CGI programs on your server machine:

• Specify a directory that contains only CGI programs. All files are run as programs regardless of the file extensions.
• Specify that CGI programs are all a certain file type. That is, they will all use the file extensions .cgi, .exe, or .bat. The programs can be located in any directory the server can serve from.

There are benefits to either implementation. If you want only a specific set of users to be able to add CGI programs, keep the CGI programs in specified directories and restrict access to those directories. If you want to allow anyone who can add HTML files to be able to add CGI programs, use the file type alternative. Users can keep their CGI files in the same directories as their HTML files.

If you choose the directory option, your server will attempt to interpret any file you place in that directory as a CGI program. By the same token, if you choose the file type option, your server will attempt to process any files with the file extensions .cgi, .exe, or .bat as CGI programs. If a file has one of these extensions but is not a CGI program, an error occurs when a user attempts to access it.

8.1.2.1 Specifying a CGI-only directory

To specify a CGI-only directory:

1. From the Server Manager, choose Programs | CGI Directory. The CGI Directory form appears.
2. In the URL Prefix field, type the URL prefix you want to use for this directory. That is, the text you type appears as the directory for the CGI programs in URLs. For example, if you type cgi-bin as the URL prefix, then all URLs to these CGI programs have the following structure:

   http://yourserver.domain.com/cgi-bin/program-name

   Note The URL prefix you specify can be different from the real CGI directory you specify in the next step.

3. In the CGI Directory text field, type the location of the directory as an absolute path. Note that this directory doesn't have to be under your document root. This is the reason that you need to specify a URL prefix in the previous step.
4. Click OK and then Save and Apply.

To remove an existing CGI directory, click that directory's Remove button in the CGI Directory form. To change the URL prefix or CGI directory of an existing directory, click that directory's Edit button.

Copy your CGI programs into the directories you've specified. Remember--any file in those directories will be processed as a CGI file, so you don't want to put HTML files in your CGI directory.

8.1.2.2 Specifying CGI as a file type

To specify CGI programs as a file type:

1. From the Server Manager, choose Programs | CGI File Type. The CGI as a File Type form appears.
2. From the Resource Picker, choose the resource you want this change to apply to.
3. Select the Yes radio button.
4. Click OK and then Save and Apply.

The CGI files must have the file extensions .bat, .exe, or .cgi. Any non-CGI files with those extensions will be processed by your server as CGI files, causing errors.

8.1.2.3 Downloading executable files

If you're using .exe as a CGI file type, users will not be able to download .exe files as executables.

One solution to this problem is to compress the executable files that you want users to be able to download, so that the extension is not .exe. This solution has the added benefit of making the download time shorter.

Another possible solution is to remove .exe as a file extension from the magnus-internal/cgi type and add it instead to the application/octet-stream type (the MIME type for normal downloadable files). However, after making this change you cannot use .exe files as CGI programs.

To do this, complete the following:

1. From the Server Manager, choose Server Preferences | MIME Types.
2. Click Edit next to the magnus-internal/cgi content-type. This displays the Edit MIME Type form.
3. Delete exe from the list of extensions.
4. Click Change Mime Type and then Save and Apply.

Another solution is to edit your server's obj.conf file to set up a download directory, where any file in the directory is downloaded automatically. The rest of the server won't be affected. For directions on setting up this directory, see the technical note at:

http://help.netscape.com/kb/server/960513-130.html

8.1.3 Using the query handler

You can specify a default query handler CGI program. A query handler processes text sent to it via the ISINDEX tag in an HTML file.

ISINDEX is similar to a form text field in that it creates a text field in the HTML page that can accept typed input. Unlike the information in a form text field, however, the information in the ISINDEX box is immediately submitted when the user presses Return. When you specify your default query handler, you tell your server to which program to direct the input. For an in-depth discussion of the ISINDEX tag, see an HTML reference manual.

To set a query handler, do the following:

1. From the Server Manager, choose Programs | Query Handler.
2. Use the Resource Picker to select the resource you want to set a default query handler for. If you choose a directory, the query handler you specify runs only when the server receives a URL for that directory or any file in that directory.
3. In the Default Query Handler field, enter the full path for the CGI program you want to use as the default for the resource you chose.
4. Click OK and then Save and Apply.

Web Application Interface (WAI) services are a kind of plug-in that use the Common Object Request Broker Architecture (CORBA).

Before you use WAI services, you must enable them on your server. Enabling WAI services essentially turns on Internet Inter-ORB Protocol (IIOP) support on the server. You may have other (non-WAI) applications that need this support. If you need IIOP support, enable WAI services.

To enable WAI services on your server:

1. From the Server Manager, choose Programs | WAI Management.
2. The WAI Administration page appears. To enable WAI services, select the Yes radio button.
3. Click OK and then Save and Apply.

For more information about WAI, see Writing Web Applications with WAI on Netscape's DevEdge online documentation web site at:

http://developer.netscape.com/library/documentation/

8.1.5 Installing server-side JavaScript programs

To install server-side JavaScript programs, you need to activate server-side JavaScript for your server and use the Application Manager. This section includes information on accessing and using the Application Manager to install server-side JavaScript applications, as well as perform other functions.

For more information about writing JavaScript applications, see Writing Server-Side JavaScript Applications on Netscape's DevEdge online documentation web site at:

http://developer.netscape.com/library/documentation/.

8.1.5.1 Activating server-side JavaScript

If you are using server-side JavaScript applications, you must first activate server-side JavaScript for your server.

To enable server-side JavaScript:

1. From the Server Manager, choose Programs | Server Side JavaScript.
2. Choose Yes under "Activate the Server Side JavaScript application environment."
3. If you want to require the administration server user name and password before allowing access to the Application Manager, choose Yes. For more information, see Section 8.1.5.3.
4. Click OK and then Save and Apply.

For applications written in server-side JavaScript, you can perform many administrative tasks with the server-side JavaScript Application Manager. Using the Application Manager, you can do the following:

• Install a new JavaScript application. You must add an application before users can run it.
• Modify any of the attributes of an installed application (for example, its default home page, path to the .web file, and type of client-object maintenance).
• Stop, start, and restart an installed application.
• Run and debug an active application.
• Remove an installed application.

To run the Application Manager:

1. Enable server-side JavaScript for your server. See Section 8.1.5.1 for more information.
2. From the Server Manager, choose Programs | Server Side JavaScript.
3. Click the link to the Application Manager.

You can also run the Application Manager by activating server- side JavaScript and then loading the following URL in Communicator:

http://server.domain/appmgr

You see the screen in Figure 8-1.

Figure 8-1 Application Manager

The Application Manager displays all applications currently installed on the server in a scrolling list in the left frame. Select an application by clicking its name in the scrolling list.

For the selected application, the right frame displays:

• The application name at the top of the frame.
• The path of the application .web file on the server.
• The default and initial pages for the application.
• The number of built-in database connections allowed.
• The external libraries used by the application (if any).
• The client object maintenance technique.
• The status of the application: active or stopped. Users can run only active applications. Stopped applications are not accessible.

Click the task buttons in the left frame to perform the indicated action on the selected application. For example, to modify the installation parameters of the selected application, click Modify.

Click Configure to configure the default settings for Application Manager. Click Add Application to add/install a new JavaScript application. Click Documentation for further documentation on server-side JavaScript. Click Help for instructions on using the Application Manager.

8.1.5.3 Securing the Application Manager

Consequently, you may want to restrict access to the Application Manager URL and the application URI so that only you and any other trusted administrators can access them. If you don't restrict access to the Application Manager, anyone can add, remove, modify, start, and stop applications on your server.

If you want to require the administration server user name and password for access to the Application Manager, follow these steps:

1. From the Server Manager, choose Programs | Server Side JavaScript.
2. Under "Require administration server password for Server Side JavaScript Application Manager" select the Yes radio button.
3. Choose OK and then Save and Apply.

You then must enter the administration server user name and password to use the Application Manager.

If your server does not use the Secure Sockets Layer (SSL), the user name and password for the Application Manager are transmitted unencrypted over the network. Any intruder who intercepts this data may be able to access the Application Manager. If you use the same password for your administration server, the intruder can also control your server. For security reasons, do not use the Application Manager from outside of your firewall unless you are using SSL.

8.1.5.4 Installing server-side JavaScript applications

You can install up to 120 JavaScript applications on one server.

You must install (add) an application with the Application Manager before you can run it. To install a new application:

1. From the Server Manager, choose Programs | Server Side JavaScript.
2. Click the link to the Application Manager.
3. Click Add Application on the top of the page. The Add Application page appears.
4. In the Name field, type the name of the JavaScript application. This name defines the application URL. For example, the name of the sample Hello World application is "world," and its application URL is http://server.domain/world. This is a required field, and the name you type must be different from all other application names on the server. The name must include only alphanumeric characters and cannot include spaces. For more information on application URLs, see Section 8.1.5.5.
5. In the Web File Path field, type the absolute path to the .web file for the application. This is a required field.
6. In the Default Page field, note what file to send to a client who does not indicate a specific page for the application. This page is analogous to index.html for a standard URL. This is a required field.
7. In the Initial field, specify a page to run when the application is first started. This page only runs once during the life of the application and is used to initialize values and establish database connections. This is an optional field.
8. In the Built-in Maximum Database Connections field, specify the maximum number of database connections that this application can have at one time if you are using the built-in database object.
9. In the External Libraries field, specify the absolute paths of any libraries to be used with the application. This is an optional field. Libraries installed for one application can be used by all applications on the server.
10. In the Client Object Maintenance field, specify the mode for maintaining the client object. This can be client cookie, client URL, server IP, server cookie, or server URL.
11. After you have entered all the required information, click OK to install the application, Reset to clear all the fields, or Cancel to cancel the operation.

When you install a server-side JavaScript application, you must enter a name for it. This name determines the application URL, the URL that clients use to access a JavaScript application. Application URLs are of the form:

http://server.domain/appName/page.html

where server is the name of the HTTP server, domain is the Internet domain (including any subdomains), appName is the application name you enter when you install it, and page is the name of a page in the application.

For example, if your server is named myserver and your domain name is mozilla.com, the application URL for the Hello World sample application is http://myserver.mozilla.com/world/hello.html.

When a client requests this URL, the server generates HTML for the specified page in the application and sends it to the client.

Using the previous example, any requests for URLs that begin with http://myserver.mozilla.com/world will look for documents in the js/samples/world directory and not in your server's normal document root.

8.1.5.6 Controlling access to a server-side JavaScript application

When you install an application, you may want to restrict its use to only certain users. You can do this by applying a configuration style to the application.

8.1.5.7 Modifying installation parameters

To modify an application's installation parameters:

1. Bring up the Application Manager as described in Section 8.1.5.2.
2. Select the application name in the left frame of the Application Manager and click Modify.

You can change any of the parameters defined when you installed the application, except the application name. To change the name of an application, you must remove the application and then reinstall it.

If you modify the parameters of a stopped application, the Application Manager automatically starts it. When you modify parameters of an active application, Application Manager automatically stops and restarts it.

8.1.5.8 Removing a server-side JavaScript application

To remove an installed application:

1. Bring up the Application Manager as described in Section 8.1.5.2.
2. Select the application name in the left frame of the Application Manager and click Remove. This action removes the application from the Application Manager but does not delete files from the server. At this point, clients can no longer access the application.

If you delete an application, and you subsequently want to run it, you must install it again.

8.1.5.9 Starting, stopping, and restarting a server-side JavaScript application

To start, stop, or restart an installed application:

1. Bring up the Application Manager as described in Section 8.1.5.2.
2. Select the application name in the left frame of the Application Manager.
   • Click Start to start a stopped application. If the application starts successfully, clients can run the application.
   • To stop an active application, click Stop. The application's status changes to "stopped," and clients can no longer run the application. You must stop an application if you want to move the .web file or update an application from a development server to a deployment server.
   • To restart a running application, click Restart. For any changes you have made to take effect, you must restart an application after you compile it.

You can also start, stop, and restart an application by entering a special URL of the form:

http://server.domain/appmgr/control.html?name=appName&cmd=action

where appName is the application name and action is either stop, start, or restart.

8.1.5.10 Running a server-side JavaScript application

There are two ways to run an installed application:

• Select the application name in the Application Manager, and click Run.
• Type the application URL in Navigator.

If you attempt to run a stopped application (one that is not active), then the Application Manager tries to start it first.

8.1.5.11 Configuring default settings

To configure default parameter settings for the Application Manager:

1. Bring up the Application Manager as described in Section 8.1.5.2.
2. Click Configure on the top of the page.

When you install a new application, the default installation parameters are used for the initial settings.

You can specify the following default settings:

• Installation parameters: .web file path, default page, initial page, maximum number of built-in database connections, external libraries, and client object maintenance technique. You can specify a default directory path for your development area and native executables libraries.
• Whether you are prompted to confirm your action when you remove, start, stop, or restart an application.
• When debugging an application, whether the application trace appears in the same window as the application but in another frame, or in a window separate from the application.

Installing client-side programs in your server is relatively easy. There are two types of client-side programs: Java applets and JavaScript programs. Client-side Java applets are executable files identified in an HTML document, retrieved from the server, and executed on the client. The applets can reside anywhere under your server's primary document root. Client-side JavaScript programs are embedded in HTML files and executed on the client.

8.2.1 Installing client-side Java applets

Instructions for creating client-side Java applets are outside the scope of this book. After you've created an applet, to install it you must copy it into a directory from which your server can deliver it. To send it to a client, it must be referenced in an HTML file.

8.2.2 Installing client-side JavaScript programs

Client-side JavaScript programs are created by lines of JavaScript code embedded in HTML files. The HTML files travel from the server to the client. Once the files reach the client, Communicator interprets the JavaScript code and performs the specified actions.

With LiveConnect you can connect server-side Java and JavaScript applications, or client-side Java and JavaScript applications. For more information on LiveConnect, on embedding JavaScript in HTML, and on using client-side JavaScript with other programs, refer to the documentation on the DevEdge online documentation web site at:

http://developer.netscape.com/library/documentation/

You can monitor your server's activity using several different methods. You can view the server's status in real time by using the Hypertext Transfer Protocol (HTTP). You can also monitor your server by recording and viewing log files.

9.1 Working with log files

Server log files record your server's activity. You can use these logs to monitor your server and to help you when troubleshooting. The error log file, located in httpd-servername/logs in the server root directory, lists all the errors the server has encountered. The access log, located in httpd-servername/logs in the server root directory, records information about requests to the server and the responses from the server. You can use the Server Manager to specify what to include in the access log file. Use the log analyzer to generate server statistics. You can back up server error and access log files by archiving them.

9.1.1 Viewing an access log file

You can view the server's active and archived access log files from the Server Manager.

To view an access log:

1. From the Server Manager, choose Server Status | View Access Log. The View Access Log form appears.
2. Choose the access log file you want to see. Active log files for resources and archived log files appear in the list.
3. To limit how much of the access log you see, type the number of lines you want to see in the "Number of entries" field. The order of the log entries on the screen is the order in which they were recorded in the log.
4. If you'd like to filter the access log entries for a particular word, type the word in the "Only show entries with" field. Case is important; make sure the case for your entry matches the case of the word you're searching for. (For example, if you want to see only those access log entries that contain "POST," type POST.)
5. Click OK.

Here is an example of an access log in the Common Logfile Format:

wiley.a.com - - [16/Feb/1996:21:18:26 -0800] "GET / HTTP/1.0" 200 751 wiley.a.com - - [17/Feb/1996:1:04:38 -0800] "GET /docs/grafx/icon.gif HTTP/1.0" 204 342 wiley.a.com - - [20/Feb/1996:4:36:53 -0800] "GET /help HTTP/1.0" 401 571 arrow.a.com - john [29/Mar/1996:4:36:53 -0800] "GET /help HTTP/1.0" 401 571

Table 9-1 describes the last line of the sample access log.

Table 9-1 Last Line of Sample Access Log File

Access Log Field	Example
Hostname or IP address of client	arrow.a.com. (In this case, the hostname is shown because the web server's setting for DNS lookups is enabled; if DNS lookups were disabled, the client's IP address would appear. )
RFC 931 information	(RFC 931 identity not implemented)
User name	john (user name entered by the client for authentication)
Date/time of request	29/Mar/1996:4:36:53 -0800
Request	GET /help
Protocol	HTTP/1.0
Status code	401
Bytes transferred	571

Here is an example of an access log using the flexible logging format:

wiley.a.com - - [25/Mar/1996:12:55:26 -0800] "GET /index.htm HTTP/1.0" "GET" "/?-" "HTTP/ 1.0" 304 0 - Mozilla/2.0 (WinNT; I) wiley.a.com - - [25/Mar/1996:12:55:26 -0800] "GET / HTTP/1.0" "GET" "/?-" "HTTP/1.0" 304 0 - Mozilla/2.0 (WinNT; I) wiley.a.com - - [25/Mar/1996:12:55:26 -0800] "GET / HTTP/1.0" "GET" "/?-" "HTTP/1.0" 304 0 - Mozilla/2.0 (X11; I; IRIX 5.3 IP22)

The access log in the flexible logging format looks similar to the access log using the Common Logfile Format.

9.1.2 Viewing the error log file

The error log file contains errors the server has encountered since the log file was created; it also contains informational messages about the server, such as when the server was started. Incorrect user authentication is also recorded in the error log. Use the error log to find broken URL paths or missing files.

To view the error log file:

1. From the Server Manager, choose Server Status | View Error Log. The View Error Log form appears.
2. If you want to see more or less than 25 lines of the error log, use the "Number of errors to view" field to enter the number of lines you'd like to see. The order of the log entries on the screen is the order in which they were recorded in the log.
3. If you'd like to filter the error messages for a particular word, type the word in the "Only show entries with" field. Case is important; make sure the case for your entry matches the case of the word you're searching for. (For example, if you want to see only those error messages that contain "warning," type warning.)
4. Click OK.

Here is an example of an error log:

[13/Feb/1996:16:56:51] info: successful server startup [20/Mar/1996 19:08:52] warning: for host wiley.a.com trying to GET /report.html, append-trailer reports: error opening /usr/ns- home/docs/report.html (No such file or directory) [30/Mar/1996 15:05:43] security: for host arrow.a.com trying to GET /, basic-ncsa reports: user jane password did not match database /usr/ns- home/authdb/mktgdb

In this example, the first line is an informational message--the server started up successfully. The second log entry shows that the client wiley.a.com requested the file report.html, but the file wasn't in the primary document directory on the server. The third log entry shows that the password entered for the user jane was incorrect.

9.1.3 Setting log preferences

During installation, an access log file named access was created for the server. You can customize access logging for any resource by specifying whether to log accesses, what format to use for logging, and whether the server should spend time looking up the domain names of clients when they access a resource.

Server access logs can be in Common Logfile Format, flexible log format, or your own customizable format. The Common Logfile Format is a commonly supported format that provides a fixed amount of information about the server. The flexible log format allows you to choose (from the Server Manager) what to log. A customizable format uses parameter blocks that you specify to control what gets logged. Once an access log for a resource has been created, you can't change its format unless you archive it or create a new access log file for the resource.

To set access logging preferences:

1. From the Server Manager, choose Server Status | Log Preferences. The Log Preferences form appears.
2. Use the Resource Picker to choose the resource you'd like to apply custom logging to.
3. Select whether to log client accesses.
4. Type the full path for the log file. As a default, the log files are kept in the logs directory in the server root directory. If you specify a partial pathname, the server assumes the path is the logs directory in the server root.
5. Choose whether to record domain names or IP addresses in the access log.
6. Choose the format in which the log file should be: Common Logfile Format, flexible log format (Only log radio button), or custom format. If you select Only log, you can choose any or all of the following flexible log format items:
   • Client hostname--The hostname (or IP address if DNS is disabled) of the client requesting access.
   • Authenticate user name--If authentication is necessary, you can have the authenticated user name listed in the access log.
   • System date--The date and time of the client request.
   • Full request--The exact request the client made.
   • Status--The status code the server returned to the client.
   • Content length--The content length, in bytes, of the document sent to the client.
   • HTTP header, "referer"--The referer specifies the page from which the client accessed the current page. For example, if a user was looking at the results from a text search query, the referer would be the page from which the user accessed the text search engine. Referers allow the server to create a list of backtracked links.
   • HTTP header, "user-agent"-- The user-agent information--which includes the type of browser the client is using, its version, and the operating system it's running on. This information comes from the User-agent field in the HTTP header the client sends to the server.
   • Method--The request method used.
   • URI--Universal Resource Identifier. The location of a resource on the server. For example, for http://www.a.com:8080/special/docs, the URI is special/docs.
   • Query string of the URI--Anything after the question mark in a URI. For example, for http://www.a.com:8080/special/docs?find_this, the query string of the URI is find_this.
   • Protocol--The transport protocol and version used.
   
   If you choose a custom format; type your custom format in the Custom format field. For more information about the parameters you should use, see Netscape's DevEdge online documentation web site at:

   http://developer.netscape.com/library/documentation/

   
   

7. If you don't want to log client access from certain hostnames or IP addresses, type them in the Hostnames and IP Addresses fields. Type a wildcard pattern of hosts the server should ignore when recording accesses. For example, use *.netscape.com if you don't want to log accesses from clients whose domain is netscape.com. You can type wildcard patterns for hostnames, IP addresses, or both.
8. Choose whether to include the format string in the log file. If you are using the proxy server's log analyzer, you should include a format string. If you are using a third-party analyzer, you may not want to include a format string in your log file.
9. Click OK and then Save and Apply.

You can archive the access and error log files and have the server create new ones.

When you archive log files, the server renames the current log files and then creates new log files with the original names. You can back up or archive (or delete) the old log files, which are saved as the original filename followed by the date and time the file was rotated. For example, access might become access.24Apr-04AM.

You can archive log files immediately or have the server archive log files at a specific time on specific days. The information about when to archive log files is stored in the cron.conf file in the admin-serv directory in the server root directory; the server's cron configuration options are stored in ns-cron.conf in the admin-serv directory.

To archive log files:

1. From the Server Manager, choose Server Status | Archive Log. The Archive Log Files form appears.
2. Click Archive if you want to rotate the log files immediately. If you want archiving to occur at specific times on specific days, click the "Rotate log at" button, choose a time from the pull-down menu, and select the days for archiving to occur.
3. Click OK and then Save and Apply.
4. Shut down the administration server by clicking the "shut down" link on the page that appears.
5. Restart the administration server.

You can monitor your server's usage with the interactive server monitor. You can see how many requests your server is handling and how it is handling these requests. If the interactive server monitor reports that the server is handling a great number of requests, you may need to adjust the server configuration or the system's network kernel to accommodate the requests.

To monitor your server:

1. From the Server Manager, choose Server Status | Monitor Current Activity.
2. Click "Monitor current activity on port port_number". The interactive server monitor appears.

The interactive server monitor reports the totals for the following server values:

• Bytes transferred - the number of bytes the server is transferring
• Total requests - the number of requests the server is handling
• Bad requests - the number of bad requests the server is handling
• 2xx - the number of status codes ranging from 200 to 299 that the server is handling
• 3xx - the number of status codes ranging from 300 to 399 that the server is handling
• 4xx - the number of status codes ranging from 400 to 499 that the server is handling
• 5xx - the number of status codes of 500 and higher that the server is handling
• xxx - the total number of 2xx, 3xx, 4xx, and 5xx status codes the server is handling minus timeouts and other errors that did return an HTTP status code
• 200 - the number of successful transactions the server is processing
• 302 - the number of relocated URL status codes the server is processing
• 304 - the number of requests for which the server tells the client to use a local copy of a URL instead of retrieving a newer version from the server
• 401 - the number of unauthorized requests the server is handling
• 403 - the number of forbidden URL status codes the server is handling

Use the log analyzer to generate statistics about your server, such as a summary of activity, most commonly accessed URLs, times during the day when the server is accessed most frequently, and so on. You can run the log analyzer from the Server Manager or the command line.

To run the log analyzer from the Server Manager:

1. From the Server Manager, choose Server Status | Generate Report. The Generate Report form appears.
2. Type the name of your server; this name appears in the generated report.
3. Choose whether the report will appear in HTML or plain text format.
4. Select the log file you want to analyze.
5. If you want to save the results in a file, type an output filename in the Output file field. If you leave the field blank, the analyzer prints results on the screen. For large log files, you should save the results to a file because printing the output to the screen might take a long time.
6. Select whether to generate totals for certain server statistics. You can generate the following totals:
   • Total hits--The total number of hits the server received since access logging was enabled.
   • 304 (Not Modified) status codes--The number of times the requesting client used a local copy of the requested document, rather than retrieving it from the server.
   • 302 (Redirects) status codes--The number of times the server redirected to a new URL because the original URL moved.
   • 404 (Not Found) status codes--The number of times the server couldn't find the requested document or the server didn't serve the document because the client was not an authorized user.
   • 500 (Server Error) status codes--The number of times a server-related error occurred.
   • Total unique URLs--The number of unique URLs accessed since access logging was enabled.
   • Total unique hosts--The number of unique client hosts who have accessed the server since access logging was enabled.
   • Total kilobytes transferred--The number of kilobytes the server transferred since access logging was enabled.
7. Select whether to generate general statistics. You can generate the following general statistics:
   • Top number of one-second periods--You can generate the number of one-second periods during which requests were highest.
   • Top number of one-minute periods--You can generate the number of one-minute periods during which requests were highest.
   • Top number of one-hour periods--You can generate the number of one-hour periods during which requests were highest.
   • Top number of users--You can generate the top number of users that accessed your server, provided that you included this as an item to log when you enabled access logging.
   • Top number of referers--You can generate the number of referers that appear in your log analysis, provided that you included this as an item to log when you enabled access logging.
   • Top number of user agents--You can generate the number of user agents that appear in your log analysis, provided that you included this as an item to log when you enabled access logging.
   • Top number of miscellaneous logged items--You can generate the number of miscellaneous logged items that appear in your log analysis, provided that you included this as an item to log when you enabled access logging. These miscellaneous items include the request method, the URI, and the URI query.
8. Select whether to generate a list of server access statistics. You can generate a list of the following:
   • Most commonly accessed URLs--You can have the log analyzer show the most commonly accessed URLs or URLs that were accessed more than a specified number of times.
   • Hosts most often accessing your server--You can have the log analyzer show the hosts most often accessing your server or hosts that have accessed your server more than a specified number of times.
9. Specify the order in which you want to see the results.
10. Click OK.

	privacy and legal statement
6563PRO_002.HTML