Netscape Communications Corporation ("Netscape") and its licensors retain all ownership rights to the software programs offered by
Netscape (referred to h er e in as "Software") and related d oc u m en t at ion. Use of the Software and relat e d doc umentation is governe d
by the license agreement for the Software and applicable copyright law.
Your right to copy this documen tatio n is l imited by copyr ight la w. Making un auth orized copies, adaptati ons or compila tio n works is
prohibited and constitutes a punishable violation of the law. Netscape may revise thi s documentation from time to time without
notice.
THIS DOCUMENTATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. IN NO EVENT SHALL NETSCAPE BE
LIABLE FOR INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY KIND ARISING FROM ANY
ERROR IN THIS DOCUMENTATION, INCLUDING WITHOUT LIMITATION ANY LOSS OR INTERRUPTION OF BUSINESS,
PROFITS, USE, OR DATA.
This product includes software developed by Apache Softwa re Foun d at ion (h t tp:// www.apache.org/). Copyri gh t (c ) 1999 The
Apache Software Foundation . All right s reserved.
This product includes software developed by the Universit y of California, Berkeley and its con t rib u tors. Copyright (c) 1990, 1993,
1994 The Regents of the U n iv e rsity of California. All rights re se rved.
Netscape and the Netscape N logo are registered trademarks of Netscape Communications Corporation in the United States and
other countries. Other N etscape logos, product names and serv ice names are also trademarks of Netsc ape an d m ay b e re gist ere d in
some countries. Sun, Sun Microsystems, and the Sun logo, iPlanet, and the iPlanet logo are trademarks or registered trademarks of
Sun Microsystems, Inc. in the U ni ted States and other countries. Other prod uct an d brand names are trademarks of the ir re spect ive
owners.
The downloading, exporting, or reexporting of Netscape software or any underlying information or technology must be in full
compliance with all United States and other applicable laws and regulations. Any provision of Netscape software or documentation
to the U.S. government is with restricted rights as described in the license agreement for that Software.
14Netscape Enterprise Server NSAPI Programmer’s Guide • November 2001
About This Book
This book discusses how to use the Netscape® Server Application Programmer's
Interface (NSAPI) to build plugins that define Server Application Functions (SAFs)
to extend and modify Netscape Enterprise Server. The book also discusses the
purpose and use of the configuration files
mime.types, and provides comprehensive lists of the directives and functions that
can be used in these configuration files. It also provides a reference of the NSAPI
functions you can use to define new plugins.
This book has the following chapters and appendices:
•Chapter 1, “Basics of Server Operation”
This chapter discusses how the uses configuration files to perform
initialization tasks and to process client requests.
obj.conf, magnus.conf, server.xml, and
•Chapter 2, “Syntax and Use of obj.conf”
This chapter goes into detail on the configuration file
discusses the syntax and use of directives in this file, which instruct the server
how to process requests.
•Chapter 3, “Predefined SAFs and the Request Handling Process”
This chapter discusses each of the stages in the request handling process, and
provides an API reference of the Server Application Functions (SAFs) that can
be invoked at each stage.
•Chapter 4, “Creating Custom SAFs”
This chapter discusses how to create your own plugins that define new SAFs to
modify or extend the way the server handles requests.
•Chapter 5, “NSAPI Function Reference”
This chapter presents a reference of the functions in the Netscape Server
Application Programming Interface (API). You use NSAPI functions to define
SAFs.
•Chapter 6, “Examples of Custom SAFs”
obj.conf. The chapter
15
This chapter discusses examples of custom SAFs to use at each stage in the
request handling proc ess.
•Chapter 7, “Syntax and Use of magnus.conf”
This appendix discusses the variables you can set in the configuration file
magnus.conf to configure the during initialization.
•Chapter 8, “Virtual Server Configuration Files”
This appendix discusses the variables you can set in the configuration file
server.xml to configure virtual servers in .
•Appendix A, “Data Structure Reference”
This appendix discusses some of the commonly used NSAPI data structures.
•Appendix B, “MIME Types”
This appendix discusses the MIME types file, which maps file extensions to file
types.
•Appendix C, “Wildcard Patterns”
This appendix lists the wildcard patterns you can use when specifying values
obj.conf, various predefined SAFs, and in some NSAPI functions.
in
•Appendix D, “Time Formats”
This appendix lists time formats.
•Appendix E, “HyperText Transfer Protocol”
This appendix gives an overview of HTTP.
•Appendix F, “Dynamic Results Caching Func tions”
This appendix explains how to create a results caching plugin.
•Appendix G, “Alphabetica l List of NSAPI Functions and M acros”
Appendix H, “Alphabetical List of Directives in magnus.conf”
Appendix I, “Alphabetical List of Pre-defined SAFs”
These appendices provide alphabetical lists for easy lookup of NSAPI
functions, predefined SAFs, and variables in
NOTEThroughout this manual, all descriptions specific to UNIX®
descriptions apply to the Linux® operating system as we ll, except
where Linux is specifically mentioned.
16Netscape Enterprise Server NSAPI Programmer’s Guide • November 2001
magnus.conf.
Chapter1
Basics of Server Operation
The configuration and behavior of Netscape Enterprise Server is determined by a
set of configuration files. You can change the s ettings in these configuration files
either by using the Server Manager interface or by manually editing the files.
The configuration file that contains instructions for how the server processes
requests from clients is called
handling process by adding or changing the instructions in
the Netscape Server Application Programming Interface (API) to create new Server
Application Functions (SAFs) to use in instructions in
This chapter discusses the configuration files used by the . Then the chapter looks
in more detail at the server’s process for handling requests. The chapter closes by
introducing the use of Netscape Server Application Programming Interface
(NSAPI) to define new functions to modify the request-handling process.
obj.conf. You can modify and extend the request
obj.conf. You can use
obj.conf.
This chapter has the following sectio ns:
•Configuration Files
•Dynamic Reconfiguration
•How the Server Handles Requests from Clients
•Writing New Server Application Functions
17
Configuration Files
Configuration Files
The configuration and operation of the is controlled by configuration files. The
configuration files reside in the directory
directory contains various configuration files for controlling different components,
such as
configuring NetShare. The exact number and na mes of con figuration f iles de pends
on which components have been enabled or loaded into the server.
However, this directory always contains four configuration files that are essential
for the server to operate. These files are:
•
•
•
•
jsa.conf for configuring server-side JavaScript and netshare.conf for
magnus.conf – contains global server initializ ation information.
server.xml – contains initialization information for virtual servers and listen
sockets.
obj.conf – contains instructions for handling requests from clients.
mime.types – contains information for determining the content type of
requested resources.
server-root/server-id/config/. This
magnus.conf
This file sets values of variables that configure the server during initialization. The
server looks at this file and executes the settings on startup. The server does not
look at this file again until it is restarted.
See Chapter 7, “Syntax and Use of magnus.conf” for a list of all the variables and
Init directives that can be set in magnus.conf.
server.xml
This file configures the addresses and ports that the server listens on and assigns
virtual server classes and virtual servers to these listen sockets. A ma ster fi le,
server.dtd, defines its format and content.
For more information about how the server uses
Chapter 8, “Virtual Server Configuration Files.”
NOTEVirtual servers are not the same thing as server instances. Each
server instance is a completely separate server that contains one or
more virtual servers.
18Netscape Enterprise Server NSAPI Programmer’s Guide • November 2001
server.dtd and server.xml, see
Configuration Files
obj.conf
This file contains instructions for the server about how to process requests from
clients (such as browsers). The server looks at the configuration defined by this file
every time it processes a request from a client.
There is one
servers. Whenever this guide refers to “the
files or to the
All the
They are typically named vsclass
obj.conf file for each virtual server class, or grouping of virtual
obj.conf file,” it refers to all obj.conf
obj.conf file for the virtual server class being described.
obj.conf files are located in the server_root/server_id/config directory.
.obj.conf, where vsclass is the virtual server class
name.
obj.conf file is essential to the operation of the . When you make changes to
The
the server through the Server Manager interface, the system automatically updates
obj.conf.
The file
obj.conf contains a series of instructions (directives) that tell the what to
do at each stage in the request-response process. Each directive invokes a Server
Application Function (SAF). These functions are written using the Netscape Se rver
Application Programming Interface (NSAPI). The comes with a set of pre-defined
SAFs, but you can also write your own using NSAPI to create new instructions that
modify the way the server handles requests.
For more information about how the server uses
obj.conf, see Chapter 2, “Syntax
and Use of obj.conf.”
mime.types
This file maps file extensions to MIME types to enable the server to determine the
content type of a requested resource. For example, requests for resources with
html extensions indicate that the client is requesting an HTML file, while requests
.
for resources with
file in GIF format.
.gif extensions indicate that the client is requesting an image
For more information about how the server uses
“MIME Types.”
mime.types, see Appendix B,
Chapter 1Basics of Server Operation19
Dynamic Reconfiguration
Dynamic Reconfiguration
You do not have to restart the server for changes to obj.conf, mime.types,
server.xml, and virtual-server-specific ACL files to take effect. All you need to do
is apply the changes by clicking the Apply link and then clicking the Load
Configuration Files button on the Apply Changes screen. If there are errors in
installing the new configuration, the previous configuration is restored.
When yo u edit
into memory that contains all the information from the dynamically configurable
files.
Every new connection references the newest configuration. Once the last session
referencing a configuration ends, the now unused old configuration is deleted.
obj.conf and apply the changes, a new configuration is loaded
How the Server Handles Requests from Clients
is a web server that accepts and responds to HyperText Transfer Protocol (HTTP)
requests. Browsers like Netscape Communicator communicate using several
protocols including HTTP, FTP, and gopher. The handles HTTP specifically.
For more information about the HTTP protocol refer to Appendix E, “HyperText
Transfer Protocol” and also the latest HTTP specification.
HTTP Basics
As a quick summary, the HTTP/1.1 protocol works as follows:
•the client (usually a browser) opens a connection to the server and sends a
request
•the server processes the request, generates a response, and closes the
connection if it finds a
The request consists of a line indicating a method such as
Resource Identifier (URI) indicating which resource is being requested, and an
HTTP protocol version separated by spaces.
This is normally followed by a number of headers, a blank line indicating the end
of the headers, and sometimes body data. Headers may provide various
information about the request or the client Body data. Headers are typically only
sent for POST and PUT methods.
20Netscape Enterprise Server NSAPI Programmer’s Guide • November 2001
Connection: Close header.
GET or POST, a Universal
How the Server Handles Requests from Clients
The example request shown below would be sent by a Netscape browser to request
the server
foo.com to send back the resource in /index.html. In this example, no
body data is sent because the method is GET (the point of the request is to get some
data, not to send it.)
GET /index.html HTTP/1.0
User-agent: Mozilla
Accept: text/html, text/plain, image/jpeg, image/gif, */*
Host: example.com
The server receives the request and processes it. It handles each request
individually, although it may process many requests simultaneously. Each request
is broken down into a series of steps that together make up the request handling
process.
The server generates a response which includes the HTTP protocol version, HTTP
status code, and a reason phrase separated by spaces. This is normally followed by
a number of headers. The end of the headers is indicated by a blank line. The body
data of the response follows. A typical HTTP response might look like this:
HTTP/1.0 200 OK
Server: Netscape-Enterprise/6.0
Content-type: text/html
Content-length: 83
The status code and reason phrase tell the client how the server handled the
request. Normally the status code 200 is returned indicating that the request was
handled successfully and the body data contains the requested item. Other result
codes indicate redirection to another server or the browser’s cache, or various types
of HTTP errors such as “404 Not Found.”
Chapter 1Basics of Server Operation21
How the Server Handles Requests from Clients
Steps in the Request Handling Process
When the server first starts up it performs some initialization and then waits for an
HTTP request from a client (such as a browser). When it receives a request, it first
selects a virtual server. For details about how the virtual server is determined, see
“Virtual Server Selection for Request Processing,” on page 295.
After the virtual server is selected, the
obj.conf file for the virtual server class
specifies how the request is handled in the following steps:
1.AuthTrans (authorization translation)
verify any authorization information (such as name and password) sent in the
request.
2.NameTrans
(name translation)
translate the logical URI into a l ocal file system path.
3.PathCheck (path checking)
check the local file system path for validity and check that the requestor has
access privileges to the requested resource on the file system.
4.ObjectType (object typing)
determine the MIME-type (Multi-purpose Internet Mail Encoding) of the
requested resource (for example.
5.Service (generate the response)
text/html, image/gif, and so on).
generate and return the response to the client.
6.AddLog (adding log entries)
add entries to log file(s).
7.Error (service)
This step is executed only if an error occurs in the previous steps. If an error
occurs, the server logs an error message and aborts the process.
22Netscape Enterprise Server NSAPI Programmer’s Guide • November 2001
Writing New Server Application Functions
Directives for Handling Requests
The file obj.conf contains a series of instructions, known as directives, that tell the
what to do at each stage in the request handling process. Each directive invokes a
Server Application Function (SAF) with one or more arguments. Each directive
applies to a specific stage in the request handling process. The stages are
AuthTrans, NameTrans, PathCheck, ObjectType, Service, an d AddLog.
For example, the following directive applies during the
document-root function with the root argument set to
the
D:/Netscape/Server4/docs. (The document-root function translates the
http://server_name/ part of the URL to the document root, which in this example
The functions invoked by the directives in obj.conf are known as Server
Application Functions (SAFs).
NameTrans stage. It calls
Writing New Server Application Functions
The comes with a variety of pre-defined SAFs that you can use to create more
directives in
provided by the NSAPI. After you write the SAF, you would add a directive to
obj.conf so that your new function gets invoked by the server at the appropriate
time.
Each SAF has its own arguments, which are passed to it by the directive in
obj.conf. Every SAF is also passed additional arguments that contain information
about the request (such as what resource was requested and what kind of client
requested it) and any other server variables created or modified by SAFs called by
previously invoked directives. Each SAF may examine, modify, or create server
variables.
obj.conf. You can also write your own SAF using the functions
Each SAF returns a result code which tells the server whether it succeeded, did
nothing, or failed.
For more information about
For more information on the pre-defined SAFs, see Chapter 3, “Predefined SAFs
and the Request Handling Process.”
For more information on writing your own SAFs, see Chapter 4, “Creating Custom
SAFs.”
obj.conf, see Chapter 2, “Syntax and Use of obj.conf.”
Chapter 1Basics of Server Operation23
Writing New Server Application Functions
24Netscape Enterprise Server NSAPI Programmer’s Guide • November 2001
Chapter2
Syntax and Use of obj.conf
The obj.conf configuration file contains directives that instruct the Netscape
Enterprise Server how to handle requests from clients. This chapter discusses
server instructions in
flow of control in
about example directives.
The sections in this chapter are:
•Server Instructions in obj.conf
•The Object Tag
obj.conf; the use of Object tags; the use of variables; the
obj.conf; the syntax rules for editing obj.conf; and a note
•Variables Defined in server.xml
•Flow of Control in obj.conf
•Syntax Rules for Editing obj.conf
•About obj.conf Directive Examples
Server Instructions in obj.conf
The obj.conf file contains directives that instruct the server how to handle
requests received from clients such as browser. These directives appear inside
OBJECT tags.
Each directive calls a function, indicating when to call it and specifying arguments
for it.
The syntax of each directive is:
Directive fn=func-name name1="
value1
"...nameN="valueN"
25
Server Instructions in obj.conf
For example:
NameTrans fn="document-root" root="D:/Netscape/Server4/docs"
Directive indicates when this instruction is executed during the request handling
process. The value is one of
Service, Error, and AddLog.
AuthTrans, NameTrans, PathCheck, ObjectType,
The value of the
to execute. All directives must supply a value for the
fn argument is the name of the Server Application Function (SAF)
fn parameter -- if there’s no
function, the instruction won’t do anything.
The remaining parameters are the arguments needed by the function, and they
vary from function to function.
Enterprise Server is shipped with a set of built-in server application functions
(SAFs) that you can use to create and modify directives in
obj.conf, as discussed
in Chapter 3, “Predefined SAFs and the Request Handling Process.” You can also
define new SAFs, as discussed in Chapter 4, “Creating Custom SAFs.”
magnus.conf file contains Init directive SAFs that initialize the server. For
The
more information, see Chapter 7, “Syntax and Use of magnus.conf.”
Summary of the Directives
Here are the categories of server directives and a description of what each does.
Each category corresponds to a stage in the request handling process. The section
“Flow of Control in obj.conf,” on page 32 explains exactly how the server decides
which directive or directives to execute in at each stage.
AuthTrans
•
Verifies any authorization information (normally sent in the Authorizat ion
header) provided in the HTTP request and translates it into a user and/or a
group. Server access control occurs in two stages. AuthTrans verifies the
authenticity of the user. Later, PathCheck tests the user’s access privileges for
the requested resource.
This example calls the document-root function with a root argument of
D:/Netscape/Server4/docs. The function document-root function translates
http://server_name/ part of the requested to URL to the document root,
the
which in this case is
http://server-name/doc1.html is translated to
D:/Netscape/Server4/docs/doc1.html.
PathCheck
•
D:/Netscape/Server4/docs. Thus a request for
Performs tests on the physical path determined by the NameTrans step. In
general, these tests determine whether the path is valid and whether the client
is allowed to access the requested resource. For example:
This example calls the find-index function with an index-names argument of
index.html,home.html. If the requested URL is a directory, this function
instructs the server to look for a file called either
index.html or home.html in
the requested directory.
ObjectType
•
Determines the MIME (Multi-purpose Internet Mail Encoding) type of the
requested resource. The MIME type has attributes
content type),
encoding and language. The MIME type is sent in the headers
type (which indicates
of the response to the client. The MIME type also helps determine which
Service directive the server should execute.
The resulting type may be:
❍A common document type such as text/html or image/gif (for example,
the file name extension
❍An internal server type. Internal types always begin with
magnus-internal.
.gif translates to the MIME type image/gif).
For example:
ObjectType fn="type-by-extension"
This example calls the type-by-extension function which causes the server to
determine the MIME type according to the requested resource’s file extension.
Chapter 2Syntax and Use of obj.conf27
Server Instructions in obj.conf
•Service
Generates and sends the response to the client. This involves setting the HTTP
result status, setting up response headers (such as content-type and
content-length), and generating and sending the response data. The default
response is to invoke the
send-file function to send the contents of the
requested file along with the appropriate header files to the client.
The default
Service method="(GET|HEAD|POST)" type="*~magnus-internal/*"
fn="send-file"
Service directive is:
This directive instructs the server to call the send-file function in response to
any request whose method is
begin with
magnus-internal/. (Note the use of the special characters *~ to
GET, HEAD, or POST, and whose type does not
mean “does not match.”)
Another example is:
Service method="(GET|HEAD)" type="magnus-internal/imagemap"
fn="imagemap"
In this case, if the method of the request is either GET or HEAD, and the type of
the requested resource is
imagemap is called.
AddLog
•
"magnus-internal/imagemap", the function
Adds an entry to a log file to record information about the transaction. For
example:
AddLog fn="flex-log" name="access"
This example calls the flex-log function to log information about the current
request in the log file named
access.
Error
•
Handles an HTTP error. This directive is invoked if a previous directive results
in an error. Typically the server handles an error by sending a custom HTML
document to the user describing the problem and possible solutions.
The server always starts handling a request by processing the directives in the
default object. However, the server switches to processing directives in another
object after the
conditions is true:
The Object Tag
NameTrans stage of the default object if either of the following
•The successful
•the physical pathname that results from the
ppath attribute of another object
When the server has been alerted to use an object other than the default object, it
processes the directives in the other object before processing the directives in the
default object. For some steps in the process, the server stops processing directives
in that a particular stage (such as the
executed, whereas for other stages the server processes all directives in that stage,
including the ones in the default object as well as those in the additional object. For
more details, see ”“Flow of Control in obj.conf,” on page 32.
NameTrans directive specifies a name argument
NameTrans stage matches the
Service stage) as soon as one is successfully
Objects that Use the name Attribute
If a NameTrans directive in the default object specifies a name argument, the server
switches to processing the directives in the object of that name before processing
the remaining directives in the default object.
For example, the following
cgi to any request whose URL starts with http://server_name/cgi/.
name
NameTrans directive in the default object assigns the
When that NameTrans directive is executed, the server starts processing directives
in the object named
<Object name="cgi">
more directives...
</Object>
cgi:
Object that Use the ppath Attribute
When the server finishes processing the NameTrans directives in the default object,
the logical URL of the request will have been converted to a physical pa thname. If
this physical pathname matches the
ppath attribute of another object in obj.conf,
the server switches to processing the directives in that object before processing the
remaining ones in the default object.
For example, the following
http://server_name/ part of the requested URL to D:/Netscape/Server4/docs/