Table of Contents | Previous | Next | Index | Bookshelf

NSAPI Programmer's Guide for iPlanet Web Server


Chapter 3
Predefined SAFs and the Request Handling Process

This chapter describes the directives and pre-defined Server Application Functions (SAFs) that are provided as standard with the iPlanet Web Server. They are used in the obj.conf file to give instructions to the server. For a discussion of the use and syntax of obj.conf, see the previous chapter, Chapter 2, "Syntax and Use of obj.conf."

This chapter includes functions that are part of the core functionality of iPlanet Web Server. It does not include functions that are available only if additional components, such as servlets, web publishing, WAI, and server-parsed HTML are enabled.

The functions and arguments described here are applicable to Enterprise Server 3.x and iPlanet Web Server 4.x. Functions and arguments that are new to iPlanet Web Server 4.x are indicated as such.

This chapter contains a section for each directive which lists all the pre-defined Server Application Functions that can be used with that directive.

The directives are:

For an alphabetical list of pre-defined SAFs, see Appendix J, "Alphabetical List of Pre-defined SAFs."

The following table lists the SAFs that can be used with each directive.

Table 3.1 
Init Stage

cache-init
cindex-init
dns-cache-init
flex-init
flex-rotate-init
init-cgi
init-clf
init-uhome
load-modules
load-types
pool-init
register-http-method
thread-pool-init

AuthTrans Stage

basic-auth
basic-ncsa
get-sslid

NameTrans Stage

assign-name
document-root
home-page
pfx2dir
pfx2dir
redirect
unix-home

PathCheck Stage

cert2user
check-acl
deny-existence
find-index
find-links
find-pathinfo
get-client-cert
load-config
nt-uri-clean
ntcgicheck
require-auth
ssl-check
ssl-logout
unix-uri-clean

ObjectType Stage

force-type
set-default-type
shtml-hacktype
type-by-exp
type-by-extension

Service Stage

add-footer
add-header
append-trailer
imagemap
index-common
index-simple
key-toosmall
list-dir
make-dir
parse-html
query-handler
remove-dir
remove-file
rename-file
send-cgi
send-file
send-range
send-shellcgi
send-wincgi
upload-file

AddLog Stage

common-log
flex-log
record-useragent

Error Stage

send-error

Init Stage

Init directives are invoked during server initialization when the server is started or restarted. These directives perform tasks such as initializing log files and loading plugins.

On Unix platforms, each Init directive has an optional LateInit parameter. If it is set to "yes" or is not provided, the function is executed by the child process after it is forked from the parent. If it is set to "no", the function is executed by the parent process before the fork. Any activities that must be performed as the user root (such as writing to a root-owned file) must be done before the fork. Any activities involving the creation of threads must be performed after the fork, with the exception of thread-pool-init, which requires the optional EarlyInit parameter to be used and set to "yes."

Upon failure, Init-class functions return REQ_ABORTED. The server logs the error according to the instructions in the Error directives, and terminates. Any other result code is considered a success.

The following Init-class functions are described in detail in this section:


cache-init

Applicable in Init-class directives.

The cache-init function controls file caching for static files, such as HTML pages, GIF files and sound files. The server caches files to improve performance. If a request is received for a file that is in the cache, the server retrieves the requested resource from the cache, which is more efficient than retrieving it from its source. File caching is enabled by default.

To optimize server speed, you should ideally have enough RAM for the server and cache because swapping can be slow. Do not allocate a cache that is greater in size than the amount of memory on the system.

Files can be cached in various ways. Small files might be read into the heap space; larger files might be cached using memory-mapping; and in some circumstance files might be cached as open file descriptors.

Note

In iPlanet Web Server 4.x, much of the functionality of the file cache is controlled by a new configuration file called nsfc.conf. For information about nsfc.conf, see the tuning chapter in the iPlanet Web Server Administrator's Guide.

Parameters:

disable

(optional) specifies whether the file cache is disabled or not. If set to anything but "false" the cache is disabled. By default, the cache is enabled.

PollInterval

(optional) specifies how often the files in the cache are checked for changes. The default is 5 seconds. In iPlanet Web Server 4.x, this parameter is ignored -- use the MaxAge parameter in the nsfc.conf file instead.

MaxNumberOfCachedFiles

(optional) maximum number of entries in the accelerator cache. The default is 4096, minimum is 32, maximum is 32K.

MaxNumberOfOpenCachedFiles

(optional) Maximum number of memory-mapped cached files that can be open simultaneously.

The default is 512, minimum is 32, maximum is 32.

MaxCachedFileSize

(optional) maximum size of a file that can be cached as a memory-mapped file.

The default is 525K.

In iPlanet Web Server 4.x, this parameter is ignored. Use the MediumFileSizeLimit parameter in nsfc.conf instead.

In iPlanet Web Server 4.x, this parameter is ignored on NT because it no longer applies to the platform.

MaxTotalCachedFileSize

(optional) total size of all files that are cached as memory-mapped files. Default is 10K, minimum is 1K, maximum is 16M.

In iPlanet Web Server 4.x, this parameter is ignored on Unix. Use the MediumFileSpace parameter in nsfc.conf instead.

In iPlanet Web Server 4.x, this parameter is ignored on NT because it no longers applies to the platform.

CacheHashSize

(optional) size of hash table for the file cache accelerator. Default is 8192K, minimum is 32, max is 32K.

Example

Init fn=cache-init PollIntervale=2 MaxNumberOfCachedFiles=8192


cindex-init

Applicable in Init-class directives.

The function cindex-init sets the default settings for common indexing. Common indexing (also known as fancy indexing) is performed by the Service function index-common. Indexing occurs when the requested URL translates to a directory that does not contain an index file or home page, or no index file or home page has been specified.

In common (fancy) indexing, the directory list shows the name, last modified date, size and description for each indexed file or directory.

Parameters:

opts

(optional) is a string of letters specifying the options to activate. Currently there is only one possible option:

Note: In Enterprise Server 3.x and previously, the search for the <TITLE> tag is case sensitive. In iPlanet Web Server 4.x, the search is no longer case-sensitive.

widths

(optional) specifies the width for each column in the indexing display. The string is a comma-separated list of numbers that specify the column widths in characters for name, last-modified date, size, and description respectively.

Note: In Enterprise Server 3.x and previous versions, the widths parameter does not work properly. It basically acts as a flag, since the actual widths (for non-zero values) are hardcoded. However, in iPlanet Web Server 4.x, the widths parameter works correctly. The default values in iPlanet Web Server 4.x are 22,18,8,33.

The final three values (corresponding to last-modified date, size, and description respectively) can each be set to 0 to turn the display for that column off. The name column cannot be turned off. The minimum size of a column (if the value is non-zero) is specified by the length of its title -- for example, the minimum size of the Date column is 5 (the length of "Date" plus one space). If you set a non-zero value for a column which is less than the length of its title, the width defaults to the minimum required to display the title.

timezone

(optional) iPlanet Web Server 4.x only. This indicates whether the last-modified time is shown in local time or in Greenwich Mean Time. The values are GMT or local. The default is local.

format

(optional) iPlanet Web Server 4.x only. This parameter determines the format of the last modified date display. It uses the format specification for the UNIX function strftime().

The default is %d-%b-%Y %H:%M.

ignore

(optional) specifies a wildcard pattern for file names the server should ignore while indexing. File names starting with a period (.) are always ignored. The default is to only ignore file names starting with a period (.).

icon-uri

(optional) specifies the URI prefix the index-common function uses when generating URLs for file icons (.gif files). By default, it is /mc-icons/. If icon-uri is different from the default, the pfx2dir function in the NameTrans directive must be changed so that the server can find these icons.

Examples

Init fn=cindex-init widths=50,1,1,0

Init fn=cindex-init ignore=*private*

Init fn=cindex-init widths=22,0,0,50

See Also

index-common, find-index, home-page

dns-cache-init

Applicable in Init-class directives.

The dns-cache-init function specifies that DNS lookups should be cached when DNS lookups are enabled. If DNS lookups are cached, then when the server gets a client's host name information, it stores that information in the DNS cache. If the server needs information about the client in the future, the information is available in the DNS cache.

You may specify the size of the DNS cache and the time it takes before a cache entry becomes invalid. The DNS cache can contain 32 to 32768 entries; the default value is 1024 entries. Values for the time it takes for a cache entry to expire (specified in seconds) can range from 1 second to 1 year; the default value is 1200 seconds (20 minutes).

Parameters

cache-size

(optional) specifies how many entries are contained in the cache. Acceptable values are 32 to 32768; the default value is 1024.

expire

(optional) specifies how long (in seconds) it takes for a cache entry to expire. Acceptable values are 1 to 31536000 (1 year); the default is 1200 seconds (20 minutes).

Example

Init fn="dns-cache-init" cache-size="2140" expire="600"


flex-init

Applicable in Init-class directives.

The flex-init function opens the named log file to be used for flexible logging and establishes a record format for it. The log format is recorded in the first line of the log file. You cannot change the log format while the log file is in use by the server.

The flex-log function writes entries into the log file during the AddLog stage of the request handling process.

The log file stays open until the server is shut down or restarted (at which time all logs are closed and reopened).

Note: If the server has AddLog Stage directives that call flex-log, the flexible log file must be initialized by flex-init during server initialization.

You may specify multiple log file names in the same flex-init function call. Then use multiple AddLog directives with the flex-log function to log transactions to each log file.

The flex-init function may be called more than once. Each new log file name and format will be added to the list of log files.

If you move, remove, or change the log file without shutting down or restarting the server, client accesses might not be recorded. To save or backup a log file, you need to rename the file and then restart the server. The server first looks for the log file by name, and if it doesn't find it, creates a new one (the renamed original log file is left for you to use). The exception to this rule is if log rotation has been enabled in iPlanet Web Server 4.x.

For information on rotating log files, see flex-rotate-init.

The flex-init function has three parameters: one that names the log file, one that specifies the format of each record in that file, and one that specifies the logging mode.

Parameters

logFileName

The name of the parameter is the name of the log file. The value of the parameter specifies either the full path to the log file or a file name relative to the server's logs directory. For example:

access="/usr/netscape/server4/https-servername/logs/access"

mylogfile = "log1"

You will use the log file name later, as a parameter to the flex-log function.

format.logFileName

specifies the format of each log entry in the log file.

For information about the format, see the "More on Log Format" section below.

relaxed.logFileName

New in iPlanet Web Server 4.0.

If you turn on relaxed logging and the logged component is one that would normally block static page acceleration, the server skips logging the component (instead it puts a blank in the log file) if static page acceleration is enabled. However, if static page acceleration is not enabled, the server logs the full value of the component.

If the value is true, on, yes, or 1, relaxed logging is on, otherwise it is off.

An unpleasant side effect of logging a variable other than Status, Content-Length, Client-Host, Full-Request, Method, Protocol, Query-String, URI, Referer, User-Agent, Authorization, and Auth-User was that, because the variable could not be provided by the internal accelerated path, the accelerated path was not used at all. Therefore, performance numbers decreased significantly for requests that would typically benefit from the accelerator, such as static files and images.

As of iPlanet Web Server 4.x, you can relax the requirements of the log subsystem by adding the relaxed parameter to the flex-init line in the obj.conf file. This changes the behavior of the server in the following ways:

More on Log Format

The flex-init function recognizes anything contained between percent signs (%) as the name portion of a name-value pair stored in a parameter block in the server. (The one exception to this rule is the %SYSDATE% component which delivers the current system date.) %SYSDATE% is formatted using the time format %d/%b/%Y:%H:%M:%S plus the offset from GMT.
(See Chapter 4, "Creating Custom SAFs," for more information about parameter blocks and Chapter 5, "NSAPI Function Reference," for functions to manipulate pblocks.)
Any additional text is treated as literal text, so you can add to the line to make it more readable. Typical components of the formatting parameter are listed in Table 3.2. Certain components might contain spaces, so they should be bounded by escaped quotes (\")
If no format parameter is specified for a log file, the common log format is used:
"%Ses->client.ip% - %Req->vars.auth-user% [%SYSDATE%]
\"%Req->reqpb.clf-request%\" %Req->srvhdrs.clf-status%
%Req->srvhdrs.content-length%"
New in iPlanet Web Server 4.0: you can now log cookies by logging the
Req->headers.cookie.name component.
iPlanet Web Server can use cache acceleration for serving static pages (as discussed in cache-init). However, some components of log format entries block this acceleration (unless the logging mode is relaxed) causing the server to use the unaccelerated path for serving static pages. (The server always uses the unaccelerated path to serve dynamically-generated pages.) The following table indicates which components of the log format entry allow static page acceleration to proceed for the current request. If the log format uses any components that do not allow static page acceleration, the performance of serving static pages may decrease significantly (unless the logging mode is relaxed).
In the following table, the components that are enclosed in escaped double quotes (\") are the ones that could potentially resolve to values that have white spaces.

Table 3.2 Typical components of flex-init formatting
Flex-log option Component Allows static page acceleration

Client Host name (unless iponly is specified in flex-log or DNS name is not available) or IP address

%Ses->client.ip%

Yes

Client DNS name

%Ses->client.dns%

Yes

System date

%SYSDATE%

Yes

Full HTTP request line

\"%Req->reqpb.clf-request%\"

Yes

Status

%Req->srvhdrs.clf-status%

Yes

Response content length

%Req->srvhdrs.content-length%

Yes

Response content type

%Req->srvhdrs.content-type%

Yes

Referer header

\"%Req->headers.referer%\"

Yes

User-agent header

\"%Req->headers.user-agent%\"

Yes

HTTP Method

%Req->reqpb.method%

Yes

HTTP URI

%Req->reqpb.uri%

Yes

HTTP query string

%Req->reqpb.query%

Yes

HTTP protocol version

\"%Req->reqpb.protocol%\"

Yes

Accept header

%Req->headers.accept%

No

Date header

\"%Req->headers.date%\"

No

If-Modified-Since header

%Req->headers.if-modified-since%

No

Authorization header

%Req->headers.authorization%

Yes

Any header value

\"%Req->headers.headername%\"

No (unless otherwise indicated for specific header names)

Name of authorized user

%Req->vars.auth-user%

Yes

Value of a cookie

\"%Req->headers.cookie.name%\"

No

Value of any variable
in Req->vars

\"%Req->vars.varname%\"

No

Examples

The first example below initializes flexible logging into the file /usr/ netscape/server4/https-servername/logs/access.

Init fn=flex-init access="/usr/netscape/server4/https-servername/logs/access" format.access="%Ses->client.ip% - %Req->vars.auth-user% [%SYSDATE%] \"%Req->reqpb.clf-request%\" %Req->srvhdrs.clf-status% %Req->srvhdrs.content-length%"

This will record the following items
This is the default format, which corresponds to the Common Log Format (CLF).
It is advisable that the first six elements of any log always be in exactly this format, because a number of log analyzers expect that as output.
The following example initializes flexible logging into the file /user/ netscape/server4/https-servername/logs/extended.

Init fn=flex-init extended="/usr/netscape/server4/https-servername/logs/extended" format.extended="%Ses->client.ip% - %Req->vars.auth-user% [%SYSDATE%] \"%Req->reqpb.clf-request%\" %Req->srvhdrs.clf-status% %Req->srvhdrs.content-length% %Req->headers.referer% \"%Req->headers.user-agent%\" %Req->reqpb.method% %Req->reqpb.uri% %Req->reqpb.query% %Req->reqpb.protocol%"

See Also

flex-rotate-init, flex-log

flex-rotate-init

Applicable in Init-class directives. New in iPlanet Web Server 4.0.

The flex-rotate-init function enables log rotation for logs that use the flexible logging format. Call this function in the Init stage of obj.conf before calling flex-init. The flex-rotate-init function allows you to specify a time interval for rotating log files. At the specified time interval, the server moves the log file to a file whose name indicates the time of moving. The flex-log function in the AddLog stage then starts logging entries in a new log file. The server does not need to be shut down while the log files are being rotated.

Note that the server keeps all rotated log files forever, so you will need to clean them up as necessary to free up disk space.

By default, log rotation is disabled.

Parameters

rotate-start

Indicates the time to start rotation. This value is a 4 digit string indicating the time in 24 hour format, for example, 0900 indicates 9 am while 1800 indicates 9 pm.

rotate-interval

Indicates the number of minutes to elapse between each log rotation.

Example

This example enables log rotation, starting at midnight and occurring every hour.

Init fn=flex-rotate-init rotate-start=2400 rotate-intervals=60

See Also

flex-init, flex-log

init-cgi

Applicable in Init-class directives.

The init-cgi function performs certain initialization tasks for CGI execution. Two options are provided: timeout of the execution of the CGI script, and establishment of environment variables.

Parameters

timeout

(optional) specifies how many seconds the server waits for CGI output. If the CGI script has not delivered any output in that many seconds, the server terminates the script. The default is 300 seconds.

env-variable

(optional) specifies the name and value for an environment variable that the server places into the environment for the CGI. You can set any number of environment variables in a single init-cgi function.

Example

Init fn=init-cgi LD_LIBRARY_PATH=/usr/lib;/usr/local/lib

See Also

send-cgi, send-wincgi, send-shellcgi

init-clf

Applicable in Init-class directives.

The init-clf function opens the named log files to be used for common logging. The common-log function writes entries into the log files during the AddLog stage of the request handling process. The log files stay open until the server is shut down (at which time the log files are closed) or restarted (at which time the log files are closed and reopened).

Note: If the server has an AddLog Stage directive that calls common-log, common log files must be initialized by init-clf during the Init stage.

Note: This function should only be called once. If it is called again, the new call will replace log file names from all previous calls.

If you move, remove, or change the log file without shutting down or restarting the server, client accesses might not be recorded. To save or backup a log file, you need to rename the file (and for Unix, send the -HUP signal) and then restart the server. The server first looks for the log file by name, and if it doesn't find it, creates a new one (the renamed original log file is left for you to use).

Parameters

 

logFileName

The name of the parameter is the name of the log file. The value of the parameter specifies either the full path to the log file or a file name relative to the server's logs directory. For example:

access="/usr/netscape/server4/https-servername/logs/access"
mylogfile = "log1"

You will use the log file name later, as a parameter to the common-log function.

Examples

Init fn=init-clf access=/usr/netscape/server4/https-boots/logs/access

Init fn=init-clf templog=/tmp/mytemplog templog2=/tmp/mytemplog2

See Also

common-log, record-useragent

init-uhome

Applicable in Init-class directives.

Unix Only. The init-uhome function loads information about the system's user home directories into internal hash tables. This increases memory usage slightly, but improves performance for servers that have a lot of traffic to home directories.

Parameters

pwfile

(optional) specifies the full file system path to a file other than /etc/passwd. If not provided, the default Unix path (/etc/passwd) is used.

Examples

Init fn=init-uhome

Init fn=init-uhome pwfile=/etc/passwd-http

See Also

unix-home, find-links

load-modules

Applicable in Init-class directives.

The load-modules function loads a shared library or Dynamic Link Library into the server code. Specified functions from the library can then be executed from any subsequent directives. Use this function to load new plugins or SAFs.

If you define your own Server Application Functions, you get the server to load them by using the load-modules function and specifying the shared library or dll to load.

Parameters

shlib

specifies either the full path to the shared library or dynamic link library or a file name relative to the server configuration directory.

funcs

is a comma separated list of the names of the functions in the shared library or dynamic link library to be made available for use by other Init or Service directives in obj.conf. The list should not contain any spaces. The dash (-) character may be used in place of the underscore (_) character in function names.

NativeThread

(optional) specifies which threading model to use.

pool

the name of a custom thread pool, as specified in thread-pool-init.

Examples

Init fn=load-modules shlib="C:/mysrvfns/corpfns.dll" funcs="moveit"

Init fn=load-modules shlib="/mysrvfns/corpfns.so" funcs="myinit,myservice"
Init fn=myinit


load-types

Applicable in Init-class directives.

The load-types function loads the file that the server uses to look up mime types.

More explicitly, this function uses the indicated file to create a table that maps file-name extensions to a file's content-type, content-encoding, and content-language. During the ObjectType phase, the function type-by-extension instructs the server to look in this table to determine the type of content requested by the client, based on the extension of the requested resource.

If you edit the MIME types file, you will need to restart the server to load the changes.

The file name extensions are not case-sensitive.

This function must be called in order for the type-by-extension and type-by-exp SAFs, and the cinfo_find NSAPI functions to work properly.

Note: MIME types files must begin with the following line or they will not be accepted:#--Netscape Communications Corporation MIME Information

Parameters

mime-types

specifies either the full path name to a MIME types file or a path name relative to the server configuration directory. The server comes with a default file called mime.types in the server's config directory.

local-types

(optional) specifies either the full path name to a MIME types file or a path name relative to the server configuration directory. The file can be used to maintain types that are applicable only to your server.

Examples

Init fn=load-types mime-types=mime.types

Init fn=load-types mime-types=mime.types local-types=/usr/netscape/server4/local.types

See Also

type-by-extension, type-by-exp, force-type

pool-init

Applicable in Init-class directives.

The pool-init function changes the default values of pooled memory settings. The size of the free block list may be changed or pooled memory may be entirely disabled.

Memory allocation pools allow the server to run significantly faster. If you are programming with the NSAPI, note that MALLOC, REALLOC, CALLOC, STRDUP, and FREE work slightly differently if pooled memory is disabled. If pooling is enabled, the server automatically cleans up all memory allocated by these routines when each request completes. In most cases, this will improve performance and prevent memory leaks. If pooling is disabled, all memory is global and there is no clean-up.

If you want persistent memory allocation, add the prefix PERM_ to the name of each routine (PERM_MALLOC, PERM_REALLOC, PERM_CALLOC, PERM_STRDUP, and PERM_FREE).

Note: Any memory you allocate from Init-class functions will be allocated as persistent memory, even if you use MALLOC. The server cleans up only the memory that is allocated while processing a request, and because Init-class functions are run before processing any requests, their memory is allocated globally.

Parameters

free-size

(optional) maximum size in bytes of free block list. May not be greater than 1048576.

disable

(optional) flag to disable the use of pooled memory. Should have a value of true or false. Default value is false.

Example

Init fn=pool-init disable=true


register-http-method

Applicable in Init-class directives. New in iPlanet Web Server 4.1.

This function lets you extend the HTTP protocol by registering new HTTP methods. (You do not need to register the default HTTP methods.)

Upon accepting a connection, the server checks to see if the method that it received is known to it. If the server does not recognize the method, it returns a "501 Method Not Implemented" error message.

Parameters

methods

is a comma separated list of the names of the methods you are registering.

Example

The following example shows the use of register-http-method and a Service function for one of the methods.

Init fn="register-http-method" methods="MY_METHOD1,MY_METHOD2" Service fn="MyHandler" method="MY_METHOD1"


thread-pool-init

Applicable in Init-class directives.

This function creates a new pool of user threads. A pool must be declared before it's used. To tell a plugin to use the new pool, specify the pool parameter when loading the plugin with the Init-class function load-modules.

One reason to create a custom thread pool would be if a plugin is not thread-aware, in which case you can set the maximum number of threads in the pool to 1.

The older parameter NativeThread=yes always engages one default native pool, called NativePool.

The native pool on Unix is normally not engaged, as all threads are OS-level threads. Using native pools on Unix may introduce a small performance overhead as they'll require an additional context switch; however, they can be used to localize the jvm.stickyAttach effect or for other purposes, such as resource control and management or to emulate single-threaded behavior for plug-ins (by setting maxThreads=1).

On Windows NT, the default native pool is always being used and iPlanet Web Server uses fibers (user-scheduled threads) for initial request processing. Using custom additional pools on Windows NT introduces no additional overhead.

In addition, native thread pool parameters can be added to the magnus.conf file for convenience. For more information, see "Native Thread Pools" in Appendix B, "Variables in magnus.conf."

Parameters

name

name of the thread pool.

maxthreads

maximum number of threads in the pool.

minthreads

minimum number of threads in the pool.

queueSize

size of the queue for the pool. If all the threads in the pool are busy, further request-handling threads that want to get a thread from the pool will wait in the pool queue. The number of request-handling threads that can wait in the queue is limited by the queue size. If the queue is full, the next request-handling thread that comes to the queue is turned away, with the result that the request is turned down, but the request-handling thread remains free to handle another request instead of becoming locked up in the queue.

stackSize

stack size of each thread in the native (kernel) thread pool.

Example

Init fn=thread-pool-init name="my-custom-pool" maxthreads=100 minthreads=1 queuesize=200

Init fn=load-modules shlib="C:/mydir/myplugin.dll" funcs="tracker" pool="my-custom-pool"

See also

load-modules

AuthTrans Stage

AuthTrans stands for Authorization Translation. AuthTrans directives give the server instructions for checking authorization before allowing a client to access resources. AuthTrans directives work in conjunction with PathCheck directives. Generally, an AuthTrans function checks if the username and password associated with the request are acceptable, but it does not allow or deny access to the request -- it leaves that to a PathCheck function.

The server handles the authorization of client users in two steps.

The authorization process is split into two steps so that multiple authorization schemes can be easily incorporated, as well as providing the flexibility to have resources that record authorization information but do not require it.

AuthTrans functions get the username and password from the headers associated with the request. When a client initially makes a request, the username and password are unknown so the AuthTrans functions and PathCheck functions work together to reject the request, since they can't validate the username and password. When the client receives the rejection, its usual response is to pop up a dialog box asking for the username and password to enter the appropriate realm, and then the client submits the request again, this time including the username and password in the headers.

If there is more than one AuthTrans directive in obj.conf, each function is executed in order until one succeeds in authorizing the user.

The following AuthTrans-class functions are described in detail in this section:


basic-auth

Applicable in AuthTrans-class directives.

The basic-auth function calls a custom function to verify authorization information sent by the client. The Authorization header is sent as part of the basic server authorization scheme.

This function is usually used in conjunction with the PathCheck-class function require-auth.

Parameters

auth-type

specifies the type of authorization to be used. This should always be basic.

userdb

(optional) specifies the full path and file name of the user database to be used for user verification. This parameter will be passed to the user function.

userfn

is the name of the user custom function to verify authorization. This function must have been previously loaded with load-modules. It has the same interface as all the SAFs, but it is called with the user name (user), password (pw), user database (userdb), and group database (groupdb) if supplied, in the pb parameter. The user function should check the name and password using the database and return REQ_NOACTION if they are not valid. It should return REQ_PROCEED if the name and password are valid. The basic-auth function will then add auth-type, auth-user (user), auth-db (userdb), and auth-password (pw, Windows NT only) to the rq->vars pblock.

groupdb

(optional) specifies the full path and file name of the user database. This parameter will be passed to the group function.

groupfn

(optional) is the name of the group custom function that must have been previously loaded with load-modules. It has the same interface as all the SAFs, but it is called with the user name (user), password (pw), user database (userdb), and group database (groupdb) in the pb parameter. It also has access to the auth-type, auth-user (user), auth-db (userdb), and auth-password (pw, Windows NT only) parameters in the rq->vars pblock. The group function should determine the user's group using the group database, add it to rq->vars as auth-group, and return REQ_PROCEED if found. It should return REQ_NOACTION if the user's group is not found.

Examples

Init fn=load-modules shlib=/path/to/mycustomauth.so funcs=hardcoded_auth

AuthTrans fn=basic-auth auth-type=basic userfn=hardcoded_auth

PathCheck fn=require-auth auth-type=basic realm="Marketing Plans"

See Also

require-auth

basic-ncsa

Applicable in AuthTrans-class directives.

The basic-ncsa function verifies authorization information sent by the client against a database. The Authorization header is sent as part of the basic server authorization scheme.

This function is usually used in conjunction with the PathCheck-class function require-auth.

Parameters

auth-type

specifies the type of authorization to be used. This should always be basic.

dbm

(optional) specifies the full path and base file name of the user database in the server's native format. The native format is a system DBM file, which is a hashed file format allowing instantaneous access to billions of users. If you use this parameter, don't use the userfile parameter as well.

userfile

(optional) specifies the full path name of the user database in the NCSA-style HTTPD user file format. This format consists of lines using the format name:password, where password is encrypted. If you use this parameter, don't use dbm.

grpfile

(optional) specifies the NCSA-style HTTPD group file to be used. Each line of a group file consists of group:user1 user2 ... userN where each user is separated by spaces.

Examples

AuthTrans fn=basic-ncsa auth-type=basic dbm=/netscape/server4/userdb/rs
PathCheck fn=require-auth auth-type=basic realm="Marketing Plans"

AuthTrans fn=basic-ncsa auth-type=basic userfile=/netscape/server4/.htpasswd grpfile=/netscape/server4/.grpfile
PathCheck fn=require-auth auth-type=basic realm="Marketing Plans"

See Also

require-auth

get-sslid

Applicable in AuthTrans-class directives.

The get-sslid function retrieves a string that is unique to the current SSL session, and stores it as the ssl-id variable in the Session->client parameter block.

If the variable ssl-id is present when a CGI is invoked, it is passed to the CGI as the HTTPS_SESSIONID environment variable.

The get-sslid function has no parameters and always returns REQ_NOACTION. It has no effect if SSL is not enabled.

Note: iPlanet Web Server 4.x incorporates the functionality of get-sslid into the standard processing of an SSL connection, so there should no longer be a need to use get-sslid as of iPlanet Web Server 4.x.

Parameters

none

NameTrans Stage

NameTrans stands for Name Translation. NameTrans directives translate virtual URLs to physical directories on your server. For example, the URL

   http://www.test.com/some/file.html
could be translated to the full file-system path

   /usr/netscape/server4/docs/some/file.html
NameTrans directives should appear in the default object. If there is more than one NameTrans directive in an object, the server executes each one in order until one succeeds.

The following NameTrans-class functions are described in detail in this section:


assign-name

Applicable in NameTrans-class directives.

The assign-name function specifies the name of an object in obj.conf that matches the current request. The server then processes the directives in the named object in preference to the ones in the default object.

For example, consider the following directive in the default object:

NameTrans fn=assign-name name=personnel from=/personnel
Let's suppose the server receives a request for http://server-name/personnel. After processing this NameTrans directive, the server looks for an object named personnel in obj.conf, and continues by processing the directives in the personnel object.

The assign-name function always returns REQ_NOACTION,

Parameters

from

is a wildcard pattern that specifies the path to be affected.

name

specifies an additional named object in obj.conf whose directives will be applied to this request.

find-pathinfo-forward

New in iPlanet Web Server 4.1.

(optional) makes the server look for the PATHINFO forward in the path right after the ntrans-base instead of backward from the end of path as the server function assign-name does by default.

The value you assign to this parameter is ignored. If you do not wish to use this parameter, leave it out.

The find-pathinfo-forward parameter is ignored if the ntrans-base parameter is not set in rq->vars. By default, ntrans-base is set.

This feature can improve performance for certain URLs by reducing the number of stats performed.

nostat

New in iPlanet Web Server 4.1.

(optional) prevents the server from performing a stat on a specified URL whenever possible.

The effect of nostat="virtual-path" in the NameTrans function assign-name is that the server assumes that a stat on the specified virtual-path will fail. Therefore, use nostat only when the path of the virtual-path does not exist on the system, for example, for NSAPI plugin URLs, to improve performance by avoiding unnecessary stats on those URLs.

When the default PathCheck server functions are used, the server does not stat for the paths /ntrans-base/virtual-path and /ntrans-base/virtual-path/* if ntrans-base is set (the default condition); it does not stat for the URLs /virtual-path and /virtual-path/* if ntrans-base is not set.

Example

# This NameTrans directive is in the default object.
NameTrans fn=assign-name name=personnel from=/a/b/c/pers
...
<Object name=personnel>
...additional directives..
</Object>

NameTrans fn="assign-name" from="/perf" find-pathinfo-forward="" name="perf"

NameTrans fn="assign-name" from="/nsfc" nostat="/nsfc" name="nsfc"


document-root

Applicable in NameTrans-class directives.

The document-root function specifies the root document directory for the server. If the physical path has not been set by a previous NameTrans function, the http://server-name/ part of the path is replace by the physical pathname for the document root.

When the server receives a request for http://server-name/somepath/somefile, the document-root function replaces http://server-name/ with the value of its root parameter. For example, if the document root directory is /usr/netscape/server4/docs, then when the server receives a request for http://server-name/a/b/file.html, the document-root function translates the pathname for the requested resource to /usr/netscape/server4/docs/a/b/file.html.

This function always returns REQ_PROCEED. NameTrans directives listed after this will never be called, so be sure that the directive that invokes document-root is the last NameTrans directive.

There can be only one root document directory. To specify additional document directories, use the pfx2dir function to set up additional path name translations.

Parameters

root

is the file system path to the server's root document directory.

Examples

NameTrans fn=document-root root=/usr/netscape/server4/docs

See also

pfx2dir

home-page

Applicable in NameTrans-class directives.

The home-page function specifies the home page for your server. Whenever a client requests the server's home page (/), they'll get the document specified.

Parameters

path

is the path and name of the home page file. If path starts with a slash (/), it is assumed to be a full path to a file.

This function sets the server's path variable and returns REQ_PROCEED. If path does not start with a slash (/), it is appended to the URI and the function returns REQ_NOACTION continuing on to the other NameTrans directives.

Examples

NameTrans fn="home-page" path="homepage.html"

NameTrans fn="home-page" path="/httpd/docs/home.html"


pfx2dir

Applicable in NameTrans-class directives.

The pfx2dir function replaces a directory prefix in the requested URL with a real directory name. It also optionally allows you to specify the name of an object that matches the current request. (See the discussion of assign-name for details of using named objects)

Parameters

from

is the URI prefix to convert. It should not have a trailing slash (/).

dir

is the local file system directory path that the prefix is converted to. It should not have a trailing slash (/).

name

(optional) specifies an additional named object in obj.conf whose directives will be applied to this request.

find-pathinfo-forward

New in iPlanet Web Server 4.1.

(optional) makes the server look for the PATHINFO forward in the path right after the ntrans-base instead of backward from the end of path as the server function pfx2dir does by default.

The value you assign to this parameter is ignored. If you do not wish to use this parameter, leave it out.

The find-pathinfo-forward parameter is ignored if the ntrans-base parameter is not set in rq->vars. By default, ntrans-base is set.

This feature can improve performance for certain URLs by reducing the number of stats performed.

Examples

In the first example, the URL http://server-name/cgi-bin/resource (such as http://x.y.z/cgi-bin/test.cgi) is translated to the physical pathname /httpd/cgi-local/resource, (such as /httpd/cgi-local/ test.cgi) and the server also starts processing the directives in the object named cgi.

NameTrans fn=pfx2dir from=/cgi-bin dir=/httpd/cgi-local name=cgi

In the second example, the URL http://server-name/icons/resource (such as http://x.y.z/icons/happy/smiley.gif) is translated to the physical pathname /users/nikki/images/resource, (such as /users/nikki/images/smiley.gif)

NameTrans fn=pfx2dir from=/icons/happy dir=/users/nikki/images

The third example shows the use of the find-pathinfo-forward parameter. The URL http://server-name/cgi-bin/resource is translated to the physical pathname /export/home/cgi-bin/resource.

NameTrans fn="pfx2dir" find-pathinfo-forward="" from="/cgi-bin" dir="/export/home/cgi-bin" name="cgi"


redirect

Applicable in NameTrans-class directives.

The redirect function lets you change URLs and send the updated URL to the client. When a client accesses your server with an old path, the server treats the request as a request for the new URL.

Parameters

from

specifies the prefix of the requested URI to match.

url

(maybe optional) specifies a complete URL to return to the client. If you use this parameter, don't use url-prefix (and vice-versa).

url-prefix

(maybe optional) is the new URL prefix to return to the client. The from prefix is simply replaced by this URL prefix. If you use this parameter, don't use url (and vice-versa).

escape

(optional) is a flag which tells the server to util_uri_escape the URL before sending it. It should be yes or no. The default is yes.

Examples

In the first example, any request for http://server-name/whatever is translated to a request for http://tmpserver/whatever.

NameTrans fn=redirect from=/ url-prefix=http://tmpserver

In the second example, any request for http://server-name/ toopopular/whatever is translated to a request for http://bigger/ better/stronger/morepopular/whatever.

NameTrans fn=redirect from=/toopopular url=http://bigger/better/stronger/morepopular


unix-home

Applicable in NameTrans-class directives.

Unix Only. The unix-home function translates user names (typically of the form ~username) into the user's home directory on the server's Unix machine. You specify a URL prefix that signals user directories. Any request that begins with the prefix is translated to the user's home directory.

You specify the list of users with either the /etc/passwd file or a file with a similar structure. Each line in the file should have this structure (elements in the passwd file that are not needed are indicated with *):

username:*:*:groupid:*:homedir:*
If you want the server to scan the password file only once at startup, use the Init-class function init-uhome.

Parameters

from

is the URL prefix to translate, usually "/~".

subdir

is the subdirectory within the user's home directory that contains their web documents.

pwfile

(optional) is the full path and file name of the password file if it is different from /etc/passwd.

name

(optional) specifies an additional named object whose directives will be applied to this request.

Examples

NameTrans fn=unix-home from=/~ subdir=public_html

NameTrans fn=unix-home from /~ pwfile=/mydir/passwd subdir=public_html

See Also

init-uhome, find-links

PathCheck Stage

PathCheck directives check the local file system path that is returned after the NameTrans step. The path is checked for things such as CGI path information and for dangerous elements such as /./and /../ and //, and then any access restriction is applied.

If there is more than one PathCheck directive, each of the functions are executed in order.

The following PathCheck-class functions are described in detail in this section:


cert2user

Applicable in PathCheck-class directives.

The cert2user function maps the authenticated client certificate from the SSL3 session to a user name, using the certificate-to-user mappings in the user database specified by userdb.

Parameters

userdb

names the user database from which to obtain the certificate.

makefrombasic

tells the function to establish a certificate-to-user mapping. If makefrombasic is present and is not 0, the directive uses basic password authentication to authenticate the user and to then create a new certificate-to-user mapping in the specified user database if no such mapping has already been created there.

The server allows the certificate-to-user mapping to be created automatically by:

require

governs the return value. If the certificate cannot be mapped successfully to a user name, and the value of require is 0, the function returns REQ_NOACTION allowing the processing of the request to continue. But if the value of require is not 0, the function returns REQ_ABORTED and sets the protocol status to 403 FORBIDDEN, causing the request to fail and the client to be given the FORBIDDEN status. The default value of require is 1.

method

specifies a wildcard pattern for the HTTP methods for which this function will be applied. If method is absent, the function is applied for any method.

Examples

# Map the client cert to a user using this userdb.
# If a mapping is not present, the request fails.
PathCheck fn="cert2user" userdb="/usr/netscape/server4/authdb/default" require="1"


check-acl

Applicable in PathCheck-class directives.

The check-acl function specifies an Access Control List (ACL) to use to check whether the client is allowed to access the requested resource. An access control list contains information about who is or is not allowed to access a resource, and under what conditions access is allowed.

Regardless of the order of PathCheck directives in the object, check-acl functions are executed first. They cause user authentication to be performed, if required by the specified ACL, and will also update the access control state.

Parameters

acl

is the name of an Access Control List.

shexp

(optional) is a wildcard pattern that specifies the path for which to apply the ACL.

bong-file

(optional) is the path name for a file that will be sent if this ACL denies access.

Examples

PathCheck fn=check-acl acl="*HRonly*"


deny-existence

Applicable in PathCheck-class directives.

The deny-existence function sends a "not found" message when a client tries to access a specified path. The server sends "not found" instead of "forbidden," so the user cannot tell whether the path exists or not.

Use this function inside a <Client> block to deny the existence of a resource to specific users. For example, these lines deny existence of all resources to any user not in the personal.com domain:

<Client dns=*~.personal.com>
PathCheck fn=deny-existence
</Client>

Parameters

path

(optional) is a wildcard pattern of the file-system path to hide. If the path does not match, the function does nothing and returns REQ_NOACTION. If the path is not provided, it is assumed to match.

bong-msg

(optional) specifies a file to send rather than responding with the "not found" message. It is a full file-system path.

Examples

PathCheck fn=deny-existence path=/usr/netscape/server4/docs/private

PathCheck fn=deny-existence bong-msg=/svr/msg/go-away.html


find-index

Applicable in PathCheck-class directives.

The find-index function investigates whether the requested path is a directory. If it is, the function searches for an index file in the directory, and then changes the path to point to the index file. If no index file is found, the server generates a directory listing.

Note that if the file obj.conf has a NameTrans directive that calls home-page, and the requested directory is the root directory, then the home page rather than the index page, is returned to the client.

The find-index function does nothing if there is a query string, if the HTTP method is not GET, or if the path is that of a valid file.

Parameters

index-names

is a comma-separated list of index file names to look for. Use spaces only if they are part of a file name. Do not include spaces before or after the commas. This list is case-sensitive if the file system is case-sensitive.

Examples

PathCheck fn=find-index index-names=index.html,home.html


find-links

Applicable in PathCheck-class directives.

Unix Only. The find-links function searches the current path for symbolic or hard links to other directories or file systems. If any are found, an error is returned. This function is normally used for directories that are not trusted (such as user home directories). It prevents someone from pointing to information that should not be made public.

Parameters

disable

is a character string of links to disable:

dir

is the directory to begin checking. If you specify an absolute path, any request to that path and its subdirectories is checked for symbolic links. If you specify a partial path, any request containing that partial path is checked for symbolic links. For example, if you use /user/ and a request comes in for some/user/directory, then that directory is checked for symbolic links.

Examples

PathCheck fn=find-links disable=sh dir=/foreign-dir

PathCheck fn=find-links disable=so dir=public_html

See Also

init-uhome, unix-home

find-pathinfo

Applicable in PathCheck-class directives.

The find-pathinfo function finds any extra path information after the file name in the URL and stores it for use in the CGI environment variable PATH_INFO.

Parameters

find-pathinfo-forward

New in iPlanet Web Server 4.1.

(optional) makes the server look for the PATHINFO forward in the path right after the ntrans-base instead of backward from the end of path as the server function find-pathinfo does by default.

The value you assign to this parameter is ignored. If you do not wish to use this parameter, leave it out.

The find-pathinfo-forward parameter is ignored if the ntrans-base parameter is not set in rq->vars when the server function find-pathinfo is called. By default, ntrans-base is set.

This feature can improve performance for certain URLs by reducing the number of stats performed in the server function find-pathinfo.

On NT, this feature can also be used to prevent the PATHINFO from the server URL normalization process (changing '\' to '/') when the PathCheck server function find-pathinfo is used. Some double-byte characters have hex values that may be parsed as URL separator characters such as \ or ~. Using the find-pathinfo-forward parameter can sometimes prevent incorrect parsing of URLs containing double-byte characters.

Examples

PathCheck fn=find-pathinfo

PathCheck fn=find-pathinfo find-pathinfo-forward=""


get-client-cert

Applicable in PathCheck-class directives.

The get-client-cert function gets the authenticated client certificate from the SSL3 session. It can apply to all HTTP methods, or only to those that match a specified pattern. It only works when SSL is enabled on the server.
If the certificate is present or obtained from the SSL3 session, the function returns REQ_NOACTION, allowing the request to proceed, otherwise it returns REQ_ABORTED and sets the protocol status to 403 FORBIDDEN, causing the request to fail and the client to be given the FORBIDDEN status.

Parameters

dorequest

controls whether to actually try to get the certificate, or just test for its presence. If dorequest is absent the default value is 0.

If a certificate is obtained from the client and verified successfully by the server, the ASCII base64 encoding of the DER-encoded X.509 certificate is placed in the parameter auth-cert in the Request->vars pblock, and the function returns REQ_PROCEED, allowing the request to proceed.

require

controls whether failure to get a client certificate will abort the HTTP request. If require is absent the default value is 1.

method

(optional) specifies a wildcard pattern for the HTTP methods for which the function will be applied. If method is absent, the function is applied to all requests.

Examples

# Get the client certificate from the session.
# If a certificate is not already associated with the
# session, request one.
# The request fails if the client does not present a
# valid certificate.

PathCheck fn="get-client-cert" dorequest="1"


load-config

Applicable in PathCheck-class directives.

The load-config function searches for configuration files in document directories and adds the file's contents to the server's existing configuration. These configuration files (also known as dynamic configuration files) specify additional access control information for the requested resource. Depending on the rules in the dynamic configuration files, the server might or might not allow the client to access the requested resource.

Each directive that invokes load-config is associated with a base directory, which is either stated explicitly through the basedir parameter or derived from the root directory for the requested resource. The base directory determines two things:

When you enable dynamic configuration files through the Server Manager interface, the system writes additional objects with ppath parameters into the obj.conf file. If you manually add directives that invoke load-config to the default object (rather than putting them in separate objects), the Server Manager interface might not reflect your changes.

If you manually add PathCheck directives that invoke load-config to the file obj.conf, put them in additional objects (created with the <OBJECT> tag) rather than putting them in the default object. Use the ppath attribute of the OBJECT tag to specify the partial pathname for the resources to be affected by the access rules in the dynamic configuration file. The partial pathname can be any pathname that matches a pattern, which can include wildcard characters.

For example, the following <OBJECT> tag specifies that requests for resources in the directory D:/Netscape/Server4/docs are subject to the access rules in the file my.nsconfig.

<Object ppath="D:/Netscape/Server4/docs/*">
PathCheck fn="load-config" file="my.nsconfig" descend=1 basedir="D:/Netscape/Server4/docs"
</Object>

Note: If the ppath resolves to a resource or directory that is higher in the directory tree (or is in a different branch of the tree) than the base directory, the load-config function is not invoked. This is because the base directory specifies the highest-level directory for which requests will invoke the load-config function.

The load-config function returns REQ_PROCEED if configuration files were loaded, REQ_ABORTED on error, or REQ_NOACTION when no files are loaded.

Parameters

file

(optional) is the name of the dynamic configuration file containing the access rules to be applied to the requested resource. If not provided, the file name is assumed to be .nsconfig.

disable-types

(optional) specifies a wildcard pattern of types to disable for the base directory, such as magnus-internal/cgi. Requests for resources matching these types are aborted.

descend

(optional) if present, specifies that the server should search in subdirectories of this directory for dynamic configuration files. For example, descend=1 specifies that the server should search subdirectories. No descend parameter specifies that the function should search only the base directory.

basedir

(optional) specifies base directory. This is the highest-level directory for which requests will invoke the load-config function and is also the directory where the server starts searching for configuration files.

If basedir is not specified, the base directory is assumed to be the root directory that results from translating the requested resource's URL to a physical pathname. For example, if the request was for http://server-name/a/b/file.html, the physical file name would be
/document-root/a/b/file.html.

Examples

In this example, whenever the server receives a request for any resource containing the substring secret that resides in D:/Netscape/Server4/docs/ nikki/ or a subdirectory thereof, it searches for a configuration file called checkaccess.nsconfig.
The server starts the search in the directory D:/Netscape/Server4/docs/ nikki, and searches subdirectories too. It loads each instance of checkaccess.nsconfig that it finds, applying the access control rules contained therein to determine whether the client is allowed to access the requested resource or not.

<Object ppath="*secret*">
PathCheck fn="load-config" file="checkaccess.nsconfig" basedir="D:/Netscape/Server4/docs/nikki" descend="1"
</Object>


nt-uri-clean

Applicable in PathCheck-class directives.

Windows NT Only. The nt-uri-clean function denies access to any resource whose physical path contains \.\, \..\ or \\ (these are potential security problems).

Parameters

None.

Examples

PathCheck fn=nt-uri-clean

See Also

unix-uri-clean

ntcgicheck

Applicable in PathCheck-class directives.

Windows NT Only. The ntcgicheck function specifies the file name extension to be added to any file name that does not have an extension, or to be substituted for any file name that has the extension .cgi.

Parameters

extension

is the replacement file extension.

Examples

PathCheck fn=ntcgicheck extension=pl

See Also

init-cgi, send-cgi, send-wincgi, send-shellcgi

require-auth

Applicable in PathCheck-class directives.

The require-auth function allows access to resources only if the user or group is authorized. Before this function is called, an authorization function (such as basic-auth) must be called in an AuthTrans directive.

If a user was authorized in an AuthTrans directive, and the auth-user parameter is provided, then the user's name must match the auth-user wildcard value. Also, if the auth-group parameter is provided, the authorized user must belong to an authorized group which must match the auth-user wildcard value.

Parameters

path

(optional) is a wildcard local file system path on which this function should operate. If no path is provided, the function applies to all paths.

auth-type

is the type of HTTP authorization used and must match the auth-type from the previous authorization function in AuthTrans. Currently, basic is the only authorization type defined.

realm

is a string sent to the browser indicating the secure area (or realm) for which a user name and password are requested.

auth-user

(optional) specifies a wildcard list of users who are allowed access. If this parameter is not provided, then any user authorized by the authorization function is allowed access.

auth-group

(optional) specifies a wildcard list of groups that are allowed access.

Examples

PathCheck fn=require-auth auth-type=basic realm="Marketing Plans" auth-group=mktg auth-user=(jdoe|johnd|janed)

See Also

basic-auth, basic-ncsa

ssl-check

Applicable in PathCheck-class directives. New in iPlanet Web Server 4.0.

If a restriction is selected that is not consistent with the current cipher settings under Security Preferences, this function opens a popup dialog which warns that ciphers with larger secret keysizes need to be enabled. This function is designed to be used together with a Client tag to limit access of certain directories to non-exportable browsers.

The function returns REQ_NOACTION if SSL is not enabled, or if the secret-keysize parameter is not specified. If the secret keysize for the current session is less than the specified secret-keysize and the bong-file parameter is not specified, the function returns REQ_ABORTED with a status of PROTOCOL_FORBIDDEN. If the bong file is specified, the function returns REQ_PROCEED, and the path variable is set to the bong filename. Also, when a keysize restriction is not met, the SSL session cache entry for the current session is invalidated, so that a full SSL handshake will occur the next time the same client connects to the server.

Requests that use ssl-check are not cacheable in the accelerator file cache if ssl-check returns something other than REQ_NOACTION.

This function supersedes the key-toosmall Service-class function that was used in Enterprise Server prior to release 4.0.

Parameters

secret-keysize

(optional) is the minimum number of bits required in the secret key.

bong-file

(optional) is the name of a file (not a URI) to be served if the restriction is not met


ssl-logout

Applicable in PathCheck-class directives.

ssl-logout invalidates the current SSL session in the server's SSL session cache. This does not affect the current request, but the next time the client connects, a new SSL session will be created. If SSL is enabled, this function returns REQ_PROCEED after invalidating the session cache entry. If SSL is not enabled, it returns REQ_NOACTION.

Parameters

None.


unix-uri-clean

Applicable in PathCheck-class directives.

Unix Only. The unix-uri-clean function denies access to any resource whose physical path contains /./, /../ or // (these are potential security problems).

Parameters

None.

Examples

PathCheck fn=unix-uri-clean

See Also

nt-uri-clean

ObjectType Stage

ObjectType directives determine the MIME type of the file to send to the client in response to a request. MIME attributes currently sent are type, encoding, and language. The MIME type sent to the client as the value of the content-type header.

ObjectType directives also set the type parameter, which is used by Service directives to determine how to process the request according to what kind of content is being requested.

If there is more than one ObjectType directive in an object, all the directives are applied in the order they appear. If a directive sets an attribute and later directives try to set that attribute to something else, the first setting is used and the subsequent ones ignored.

The obj.conf file almost always has an ObjectType directive that calls the type-by-extension function. This function instructs the server to look in a particular file (the MIME types file) to deduce the content type from the extension of the requested resource.

The following ObjectType-class functions are described in detail in this section:


force-type

Applicable in ObjectType-class directives.

The force-type function assigns a type to requests that do not already have a MIME type. This is used to specify a default object type.

Make sure that the directive that calls this function comes last in the list of ObjectType directives so that all other ObjectType directives have a chance to set the MIME type first. If there is more than one ObjectType directive in an object, all the directives are applied in the order they appear. If a directive sets an attribute and later directives try to set that attribute to something else, the first setting is used and the subsequent ones ignored.

Parameters

type

(optional) is the type assigned to a matching request (the content-type header).

enc

(optional) is the encoding assigned to a matching request (the content-encoding header).

lang

(optional) is the language assigned to a matching request (the content-language header).

charset

(optional) is the character set for the magnus-charset parameter in rq->srvhdrs. If the browser sent the Accept-charset header or its User-agent is mozilla/1.1 or newer, then append "; charset=charset" to content-type, where charset is the value of the magnus-charset parameter in rq->srvhdrs.

Examples

ObjectType fn=force-type type=text/plain

ObjectType fn=force-type lang=en_US

See Also

load-types, type-by-extension, type-by-exp

set-default-type

Applicable in ObjectType-class directives. New in iPlanet Web Server 4.1.

This function allows you to define a default charset, content-encoding, and content-language for the response being sent back to the client.

If the charset, content-encoding, and content-language have not been set for a response, then just before the headers are sent the defaults defined by set-default-type are used. Note that by placing this function in different objects in obj.conf, you can define different defaults for different parts of the document tree.

Parameters

enc

(optional) is the encoding assigned to a matching request (the content-encoding header).

lang

(optional) is the language assigned to a matching request (the content-language header).

charset

(optional) is the character set for the magnus-charset parameter in rq->srvhdrs. If the browser sent the Accept-charset header or its User-agent is mozilla/1.1 or newer, then append "; charset=charset" to content-type, where charset is the value of the magnus-charset parameter in rq->srvhdrs.

Example

ObjectType fn="set-default-type" charset="iso_8859-1"


shtml-hacktype

Applicable in ObjectType-class directives.

The shtml-hacktype function changes the content-type of any .htm or .html file to magnus-internal/parsed-html and returns REQ_PROCEED. This provides backward compatibility with server-side includes for files with .htm or .html extensions. The function may also check the execute bit for the file on Unix systems. The use of this function is not recommended.

Parameters

exec-hack

(Unix only, optional) tells the function to change the content-type only if the execute bit is enabled. The value of the parameter is not important. It need only be provided. You may use exec-hack=true.

Examples

ObjectType fn=shtml-hacktype exec-hack=true


type-by-exp

Applicable in ObjectType-class directives.

The type-by-exp function matches the current path with a wildcard expression. If the two match, the type parameter information is applied to the file. This is the same as type-by-extension, except you use wildcard patterns for the files or directories specified in the URLs.

Parameters

exp

is the wildcard pattern of paths for which this function is applied.

type

(optional) is the type assigned to a matching request (the content-type header).

enc

(optional) is the encoding assigned to a matching request (the content-encoding header).

lang

(optional) is the language assigned to a matching request (the content-language header).

charset

(optional) is the character set for the magnus-charset parameter in rq->srvhdrs. If the browser sent the Accept-charset header or its User-agent is mozilla/1.1 or newer, then append "; charset=charset" to content-type, where charset is the value of the magnus-charset parameter in rq->srvhdrs.

Examples

ObjectType fn=type-by-exp exp=*.test type=application/html

See Also

load-types, type-by-extension, force-type

type-by-extension

Applicable in ObjectType-class directives.

This function instructs the server to look in a table of MIME type mappings to find the MIME type of the requested resource according to the extension of the requested resource. The MIME type is added to the content-type header sent back to the client.

The table of MIME type mappings is created during the server's Init stage by the load-types function, which loads a MIME types file and creates the mappings. The MIME types file is usually called mime.types, but you can specify a different file by providing a different file name to load-types.

For example, the following two lines are part of the MIME types file:

type=text/html    exts=htm,html 
type=text/plain    exts=txt
If the extension of the requested resource is htm or html, the type-by-extension file sets the type to text/html. If the extension is .txt, the function sets the type to text/plain.

For more information about MIME types, see Appendix C, "MIME Types."

Parameters

None.

Examples

ObjectType fn=type-by-extension

See Also

load-types, type-by-exp, force-type

Service Stage

The Service class of functions sends the response data to the client.

Every Service directive has the following optional parameters to determine whether the function is executed. All the optional parameters must match the current request for the function to be executed.

If there is more than one Service-class function, the first one matching the optional parameters above is executed.

By default, the server sends the requested file to the client by calling the send-file function. The directive that sets the default is:

Service method="(GET|HEAD|POST)" type="*~magnus-internal/*" fn="send-file"
This directive usually comes last in the set of Service-class directives to give all other Service directives a chance to be invoked. This directive is invoked if the method of the request is GET, HEAD, or POST, and the type does not start with magnus-internal/. Note here that the pattern *~ means "does not match." For a list of characters that can be used in patterns, see Appendix D, "Wildcard Patterns."

The following Service-class functions are described in detail in this section:


add-footer

Applicable in Service-class directives. New in iPlanet Web Server 4.0.

This function appends a footer to an HTML file that is sent to the client. The footer is specified either as a filename or a URI -- thus the footer can be dynamically generated. To specify static text as a footer, use the append-trailer function.

Parameters

file

(optional) The pathname to the file containing the footer. Specify either file or uri.

By default the pathname is relative. If the pathname is absolute, pass the NSIntAbsFilePath parameter as yes.

uri

(optional) A URI pointing to the resource containing the footer. Specify either file or uri.

NSIntAbsFilePath

(optional) if the file parameter is specified, the NSIntAbsFilePath parameter determines whether the file name is absolute or relative. The default is relative. Set the value to yes to indicate an absolute file path.

type

optional parameter common to all Service-class functions

method

optional parameter common to all Service-class functions

query

optional parameter common to all Service-class functions

Examples

Service type=text/html method=GET fn=add-footer file="footers/footer1.html"

Service type=text/html method=GET fn=add-footer file="D:/netscape/server4/footers/footer1.html" NSIntAbsFilePath="yes"

See Also

append-trailer, add-header

add-header

Applicable in Service-class directives. New in iPlanet Web Server 4.0.

This function prepends a header to an HTML file that is sent to the client. The header is specified either as a filename or a URI -- thus the header can be dynamically generated.

Parameters

file

(optional) The pathname to the file containing the header. Specify either file or uri.

By default the pathname is relative. If the pathname is absolute, pass the NSIntAbsFilePath parameter as yes.

uri

(optional) A URI pointing to the resource containing the header. Specify either file or uri.

NSIntAbsFilePath

(optional) if the file parameter is specified, the NSIntAbsFilePath parameter determines whether the file name is absolute or relative. The default is relative. Set the value to yes to indicate an absolute file path.

type

optional parameter common to all Service-class functions

method

optional parameter common to all Service-class functions

query

optional parameter common to all Service-class functions

Examples

Service type=text/html method=GET fn=add-header file="headers/header1.html"

Service type=text/html method=GET fn=add-footer file="D:/netscape/server4/headers/header1.html" NSIntAbsFilePath="yes"

See Also

add-footer, append-trailer

append-trailer

Applicable in Service-class directives.

The append-trailer function sends an HTML file and appends text to the end. It only appends text to HTML files. This is typically used for author information and copyright text. The date the file was last modified can be inserted.

Returns REQ_ABORTED if a required parameter is missing, if there is extra path information after the file name in the URL, or if the file cannot be opened for read-only access.

Parameters

trailer

is the text to append to HTML documents. The string :LASTMOD: is replaced by the date the file was last modified; you must also specify a time format with timefmt. The string is unescaped with util_uri_unescape before being sent. The text can contain HTML tags and can be up to 512 characters long after unescaping and inserting the date.

timefmt

(optional) is a time format string for :LASTMOD:. For details about time formats refer to Appendix E, "Time Formats." If timefmt is not provided, :LASTMOD: will not be replaced with the time.

type

optional parameter common to all Service-class functions

method

optional parameter common to all Service-class functions

query

optional parameter common to all Service-class functions

Examples

Service type=text/html method=GET fn=append-trailer trailer="<hr><img src=/logo.gif> Copyright 1999"

# Add a trailer with the date in the format: MM/DD/YY
Service type=text/html method=GET fn=append-trailer timefmt="%D" trailer="<HR>File last updated on: :LASTMOD:"

See Also

add-footer, add-header

imagemap

Applicable in Service-class directives.

The imagemap function responds to requests for imagemaps. Imagemaps are images which are divided into multiple areas that each have an associated URL. The information about which URL is associated with which area is stored in a mapping file.

Parameters

type

optional parameter common to all Service-class functions

method

optional parameter common to all Service-class functions

query

optional parameter common to all Service-class functions

Examples

Service type=magnus-internal/imagemap method=(GET|HEAD) fn=imagemap


index-common

Applicable in Service-class directives.

The index-common function generates a fancy (or common) list of files in the requested directory. The list is sorted alphabetically. Files beginning with a period (.) are not displayed. Each item appears as an HTML link. This function displays more information than index-simple including the size, date last modified, and an icon for each file. It may also include a header and/or readme file into the listing.

The Init-class function cindex-init specifies the format for the index list, including where to look for the images.

If obj.conf contains a call to index-common in the Service stage, it must initialize fancy (or common) indexing by invoking cindex-init during the Init stage.

Indexing occurs when the requested resource is a directory that does not contain an index file or a home page, or no index file or home page has been specified by the functions find-index or home-page.

The icons displayed are .gif files dependent on the content-type of the file:

"text/*"

text.gif

"image/*"

image.gif

"audio/*"

sound.gif

"video/*"

movie.gif

"application/octet-stream"

binary.gif

directory

menu.gif

all others

unknown.gif

Parameters

header

(optional) is the path (relative to the directory being indexed) and name of a file (HTML or plain text) which is included at the beginning of the directory listing to introduce the contents of the directory. The file is first tried with .html added to the end. If found, it is incorporated near the top of the directory list as HTML. If the file is not found, then it is tried without the .html and incorporated as preformatted plain text (bracketed by <PRE> and ).

readme

(optional) is the path (relative to the directory being indexed) and name of a file (HTML or plain text) to append to the directory listing. This file might give more information about the contents of the directory, indicate copyrights, authors, or other information. The file is first tried with .html added to the end. If found, it is incorporated at the bottom of the directory list as HTML. If the file is not found, then it is tried without the .html and incorporated as preformatted plain text (enclosed by <PRE> and </PRE>).

type

optional parameter common to all Service-class functions

method

optional parameter common to all Service-class functions

query

optional parameter common to all Service-class functions

Examples

Service fn=index-common type=magnus-internal/directory method=(GET|HEAD) header=hdr readme=rdme.txt

See Also

cindex-init, index-simple, find-index, home-page

index-simple

Applicable in Service-class directives.

The index-simple function generates a simple index of the files in the requested directory. It scans a directory and returns an HTML page to the browser displaying a bulleted list of the files and directories in the directory. The list is sorted alphabetically. Files beginning with a period (.) are not displayed. Each item appears as an HTML link.

Indexing occurs when the requested resource is a directory that does not contain either an index file or a home page, or no index file or home page has been specified by the functions find-index or home-page.

Parameters

type

optional parameter common to all Service-class functions

method

optional parameter common to all Service-class functions

query

optional parameter common to all Service-class functions

Examples

Service type=magnus-internal/directory fn=index-simple

See Also

cindex-init, index-common

key-toosmall

Applicable in Service-class directives. This function is deprecated in iPlanet Web Server 4.x. It is replaced by the PathCheck-class SAF ssl-check.

The key-toosmall function returns a message to the client specifying that the secret key size for SSL communications is too small. This function is designed to be used together with a Client tag to limit access of certain directories to non-exportable browsers.

Parameters

type

optional parameter common to all Service-class functions

method

optional parameter common to all Service-class functions

query

optional parameter common to all Service-class functions

Examples

<Object ppath=/mydocs/secret/*>
<Client secret-keysize=40)
Service fn=key-toosmall
</Client>
</Object>


list-dir

Applicable in Service-class directives.

The list-dir function returns a sequence of text lines to the client in response to a request whose method is INDEX. The format of the returned lines is:

name type size mimetype
The name field is the name of the file or directory. It is relative to the directory being indexed. It is URL-encoded, that is, any character might be represented by %xx, where xx is the hexadecimal representation of the character's ASCII number.

The type field is a MIME type such as text/html. Directories will be of type directory. A file for which the server doesn't have a type will be of type unknown.

The size field is the size of the file, in bytes.

The mtime field is the numerical representation of the date of last modification of the file. The number is the number of seconds since the epoch (Jan 1, 1970 00:00 UTC) since the last modification of the file.

When remote file manipulation is enabled in the server, the obj.conf file contains a Service-class function that calls list-dir for requests whose method is INDEX.

Parameters

type

optional parameter common to all Service-class functions

method

optional parameter common to all Service-class functions

query

optional parameter common to all Service-class functions

Examples

Service fn=list-dir method="INDEX"


make-dir

Applicable in Service-class directives.

The make-dir function creates a directory when the client sends a request whose method is MKDIR. The function can fail if the server can't write to that directory.

When remote file manipulation is enabled in the server, the obj.conf file contains a Service-class function that invokes make-dir when the request method is MKDIR.

Parameters

type

optional parameter common to all Service-class functions

method

optional parameter common to all Service-class functions

query

optional parameter common to all Service-class functions

Examples

Service fn="make-dir" method="MKDIR"


parse-html

Applicable in Service-class directives.

The parse-html function parses an HTML document, scanning for embedded commands. These commands may provide information from the server, include the contents of other files, or execute a CGI program. Refer to Appendix F, "Server-Parsed HTML Tags," for server-parsed HTML commands.

Parameters

opts

(optional) are parsing options. The no-exec option is the only currently available option--it disables the exec command.

type

optional parameter common to all Service-class functions

method

optional parameter common to all Service-class functions

query

optional parameter common to all Service-class functions

Examples

Service type=magnus-internal/parsed-html method=(GET|HEAD) fn=parse-html


query-handler

Applicable in Service-class directives.

The query-handler function runs a CGI program instead of referencing the path requested. This is used mainly to support the obsolete ISINDEX tag . If possible, use an HTML form instead.

Parameters

path

is the full path and file name of the CGI program to run.

type

optional parameter common to all Service-class functions

method

optional parameter common to all Service-class functions

query

optional parameter common to all Service-class functions

Examples

Service query=* fn=query-handler path=/http/cgi/do-grep

Service query=* fn=query-handler path=/http/cgi/proc-info


remove-dir

Applicable in Service-class directives.

The remove-dir function removes a directory when the client sends an request whose method is RMDIR. The directory must be empty (have no files in it). The function will fail if the directory is not empty or if the server doesn't have the privileges to remove the directory.

When remote file manipulation is enabled in the server, the obj.conf file contains a Service-class function that invokes remove-dir when the request method is RMDIR.

Parameters

type

optional parameter common to all Service-class functions

method

optional parameter common to all Service-class functions

query

optional parameter common to all Service-class functions

Examples

Service fn="remove-dir" method="RMDIR"


remove-file

Applicable in Service-class directives.

The remove-file function deletes a file when the client sends a request whose method is DELETE. It deletes the file indicated by the URL if the user is authorized and the server has the needed file system privileges.

When remote file manipulation is enabled in the server, the obj.conf file contains a Service-class function that invokes remove-file when the request method is DELETE.

Parameters

type

optional parameter common to all Service-class functions

method

optional parameter common to all Service-class functions

query

optional parameter common to all Service-class functions

Examples

Service fn="remove-file" method="DELETE"


rename-file

Applicable in Service-class directives.

The rename-file function renames a file when the client sends a request with a New-URL header whose method is MOVE . It renames the file indicated by the URL to New-URL within the same directory if the user is authorized and the server has the needed file system privileges.

When remote file manipulation is enabled in the server, the obj.conf file contains a Service-class function that invokes rename-file when the request method is MOVE.

Parameters

type

optional parameter common to all Service-class functions

method

optional parameter common to all Service-class functions

query

optional parameter common to all Service-class functions

Examples

Service fn="rename-file" method="MOVE"


send-cgi

Applicable in Service-class directives.

The send-cgi function sets up the CGI environment variables, runs a file as a CGI program in a new process, and sends the results to the client.

For details about the CGI environment variables and their NSAPI equivalents refer to section "CGI to NSAPI Conversion" in Chapter 4, "Creating Custom SAFs."

Parameters

type

optional parameter common to all Service-class functions

method

optional parameter common to all Service-class functions

query

optional parameter common to all Service-class functions

Examples

Service fn=send-cgi

Service type=magnus-internal/cgi fn=send-cgi


send-file

Applicable in Service-class directives.

The send-file function sends the contents of the requested file to the client. It provides the content-type, content-length, and last-modified headers.

Most requests are handled by this function using the following directive (which usually comes last in the list of Service-class directives in the default object so that it acts as a default)

Service method="(GET|HEAD|POST)" type="*~magnus-internal/*" fn="send-file"
This directive is invoked if the method of the request is GET, HEAD, or POST, and the type does not start with magnus-internal/. Note here that the pattern *~ means "does not match." For a list of characters that can be used in patterns, see Appendix D, "Wildcard Patterns."

Parameters

nocache

New in iPlanet Web Server 4.1.

(optional) prevents the server from caching responses to static file requests. For example, you can specify that files in a particular directory are not to be cached, which is useful for directories where the files change frequently.

The value you assign to this parameter is ignored. If you do not wish to use this parameter, leave it out.

type

optional parameter common to all Service-class functions

method

optional parameter common to all Service-class functions

query

optional parameter common to all Service-class functions

Examples

Service type="*~magnus-internal/*" method="(GET|HEAD)" fn="send-file"

In the following example, the server does not cache static files from /export/ somedir/ when requested by the URL prefix /myurl.
<Object name=default>
...
NameTrans fn="pfx2dir" from="/myurl" dir="/export/mydir", name="myname"
...
Service method=(GET|HEAD|POST) type=*~magnus-internal/* fn=send-file
...
</Object>

<Object name="myname">
Service method=(GET|HEAD) type=*~magnus-internal/* fn=send-file nocache=""
</Object>


send-range

Applicable in Service-class directives.

When the client requests a portion of a document, by specifying HTTP byte ranges, the send-range function returns that portion.

Parameters

type

optional parameter common to all Service-class functions

method

optional parameter common to all Service-class functions

query

optional parameter common to all Service-class functions

Examples

Service fn=send-range


send-shellcgi

Applicable in Service-class directives.

Windows NT only. The send-shellcgi function runs a file as a shell CGI program and sends the results to the client. Shell CGI is a server configuration that lets you run CGI applications using the file associations set in Windows NT. For information about shell CGI programs, consult the iPlanet Web Server Administrator's Guide.

Parameters

type

optional parameter common to all Service-class functions

method

optional parameter common to all Service-class functions

query

optional parameter common to all Service-class functions

Examples

Service fn=send-shellcgi

Service type=magnus-internal/cgi fn=send-shellcgi


send-wincgi

Applicable in Service-class directives.

Windows NT only. The send-wincgi function runs a file as a Windows CGI program and sends the results to the client. For information about Windows CGI programs, consult the iPlanet Web Server Administrator's Guide.

Parameters

type

optional parameter common to all Service-class functions

method

optional parameter common to all Service-class functions

query

optional parameter common to all Service-class functions

Examples

Service fn=send-wincgi

Service type=magnus-internal/cgi fn=send-wincgi


upload-file

Applicable in Service-class directives.

The upload-file function uploads and saves a new file when the client sends a request whose method is PUT if the user is authorized and the server has the needed file system privileges.

When remote file manipulation is enabled in the server, the obj.conf file contains a Service-class function that invokes upload-file when the request method is PUT.

Parameters

type

optional parameter common to all Service-class functions

method

optional parameter common to all Service-class functions

query

optional parameter common to all Service-class functions

Examples

Service fn=upload-file

AddLog Stage

After the server has responded to the request, the AddLog directives are executed to record information about the transaction.

If there is more than one AddLog directive, all are executed.

The following AddLog-class functions are described in detail in this section:


common-log

Applicable in AddLog-class directives.

This function records request-specific data in the common log format (used by most HTTP servers). There is a log analyzer in the /extras/log_anly directory for iPlanet Web Server. The common log must have been initialized previously by the init-cgi function.

There are also a number of free statistics generators for the common log format.

Parameters

name

(optional) gives the name of a log file, which must have been given as a parameter to the init-clf Init function. If no name is given, the entry is recorded in the global log file.

iponly

(optional) instructs the server to log the IP address of the remote client rather than looking up and logging the DNS name. This will improve performance if DNS is off in the magnus.conf file. The value of iponly has no significance, as long as it exists; you may use iponly=1.

Examples

# Log all accesses to the global log file

AddLog fn=common-log

# Log accesses from outside our subnet (198.93.5.*) to
# nonlocallog

<Client ip="*~198.93.5.*">

AddLog fn=common-log name=nonlocallog

</Client>

See Also

init-clf

flex-log

Applicable in AddLog-class directives.

This function records request-specific data in a flexible log format. It may also record requests in the common log format. There is a log analyzer in the /extras/flexanlg directory for iPlanet Web Server.

There are also a number of free statistics generators for the common log format.

The log format is specified by the flex-init function call. For information about rotating logs, see flex-rotate-init.

Parameters

name

(optional) gives the name of a log file, which must have been given as a parameter to the flex-init Init function. If no name is given, the entry is recorded in the global log file.

iponly

(optional) instructs the server to log the IP address of the remote client rather than looking up and logging the DNS name. This will improve performance if DNS is off in the magnus.conf file. The value of iponly has no significance, as long as it exists; you may use iponly=1.

Examples

# Log all accesses to the global log file

AddLog fn=flex-log

# Log accesses from outside our subnet (198.93.5.*) to

# nonlocallog

<Client ip="*~198.93.5.*">

AddLog fn=flex-log name=nonlocallog

</Client>

See Also

flex-rotate-init, flex-init, init-clf, common-log, record- useragent

record-useragent

Applicable in AddLog-class directives.

The record-useragent function records the IP address of the client, followed by its User-Agent HTTP header. This indicates what version of Netscape Navigator (or other client) was used for this transaction.

Parameters

name

(optional) gives the name of a log file, which must have been given as a parameter to the init-clf Init function. If no name is given, the entry is recorded in the global log file.

Examples

# Record the client ip address and user-agent to browserlog
AddLog fn=record-useragent name=browserlog

See Also

flex-init, init-clf, common-log, record-useragent, flex-log

Error Stage

If a server application function results in an error, it sets the HTTP response status code and returns the value REQ_ABORTED. When this happens, the server stops processing the request. Instead, it searches for an Error directive matching the HTTP response status code or its associated reason phrase, and executes the directive's function. If the server does not find a matching Error directive, it returns the response status code to the client.

The following Error-class functions are described in detail in this section:


send-error

Applicable in Error-class directives.

The send-error function sends an HTML file to the client in place of a specific HTTP response status. This allows the server to present a friendly message describing the problem. The HTML page may contain images and links to the server's home page or other pages.

Parameters

path

specifies the full file system path of an HTML file to send to the client. The file is sent as text/html regardless of its name or actual type. If the file does not exist, the server sends a simple default error page.

reason

(optional) is the text of one of the reason strings (such as "Unauthorized" or "Forbidden"). The string is not case sensitive.

code

(optional) is a three-digit number representing the HTTP response status code, such as 401 or 407.

This can be any HTTP response status code or reason phrase according to the HTTP specification.

The following is a list of common HTTP response status codes and reason strings.

Examples

Error fn=send-error code=401 path=/netscape/server4/docs/errors/401.html


Table of Contents | Previous | Next | Index | Bookshelf

Last Updated: 03/01/00 09:21:58

© Copyright © 2000 Sun Microsystems, Inc. Some preexisting portions Copyright © 2000 Netscape Communications Corp. All rights reserved.