Table of Contents | Previous | Next | Index | Bookshelf

Programmer's Guide


Chapter 1. Overview

iPlanet Web Server 4.1 supports a variety of application programming interfaces (APIs) and programming technologies that enable you to do the following:

This chapter discusses the changes in the APIs that are provided with the server from version 3.x to 4.1. It also summarizes the various APIs and programming technologies supported by the server. More information on each API or programming technology is provided either in a chapter in this book, or in a separate book.

The sections in this chapter are:

API Changes Since iPlanet Web Server 3.x

API Changes Since iPlanet Web Server 4.0

Configuration Files

You can configure the iPlanet Web Server using the Server Manager interface, or by editing configuration files. The configuration files are in the config directory in the https-server_id directory in the installation directory. For example, if iPlanet Web Server is installed on a Windows NT machine in D:\Netscape\server4\, the configuration files for the server boots.mcom.com are in:

D:\Netscape\server4\https-boots.mcom.com\config
The main configuration files are magnus.conf, obj.conf, and mime.types, but there are other configuration files as well. See Chapter 2, "Configuration Files," for an overview of these configuration files.

For more detailed information about the files magnus.conf, obj.conf, and mime.types, see the NSAPI Programmer's Guide for iPlanet Web Server.

iPlanet Web Server 4.1 APIs

This section summarizes the various APIs and programming technologies supported by iPlanet Web Server 4.1, discusses how to enable the functionality in iPlanet Web Server 4.1, and mentions where to get more information about them.

The main categories of extensions and modifications you can make to the iPlanet Web Server are:

Server-Parsed HTML Tags

iPlanet Web Server 4.1 provides a C API for defining your own server-side tags. These tags can be used in addition to the standard server-side tags, such as config, include and so on, in HTML files.

Enabling Server-Parsed Tags

To activate and deactivate the parsing of server-side tags, use the Parse HTML page in the Programs tab of the Server Manager. This page enables you to switch off parsing of server-side HTML tags, or enable it with or without also enabling the exec tag. The page also allows you to specify whether to parse all files or just those with a .shtml extension.

The directives in obj.conf that enable the parsing of server-side tags are:

Init funcs="shtml_init,shtml_send" shlib="install_dir/bin/https/bin/Shtml.dll" NativeThread="no" fn="load-modules"
Service fn="shtml_send" type="magnus-internal/parsed-html" method="(GET|HEAD)"
To enable parsing of server-side tags for files with extensions other than .shtml, add the extension to the appropriate line in the mime.types file. For example, the following line in mime.types indicates that files with either a .shtml or .jbhtml extension are parsed for server-side tags.

type=magnus-internal/parsed-html exts=shtml,jbhtml
After making changes to mime.types, restart the iPlanet Web Server to update its table of MIME type mappings, since the mime.types file is only loaded when the server is initialized.

For More Information

See Chapter 3, "Server-Parsed HTML Tags," for more information about defining and using server-parsed tags.

Server-Side JavaScript

iPlanet Web Server 4.1 supports JavaScript version 1.4.

Using JavaScript, you can create dynamic HTML pages that process user input and maintain persistent data using special objects, files, and relational databases. Through JavaScript's LiveConnect functionality, your applications can access Java and CORBA distributed-object applications.

LiveConnect allows you to access Java objects from a JavaScript application. With LiveConnect, you can create an instance of a Java class from within a JavaScript script. You can also access JavaScript objects from within Java.

Some developers choose to use JavaScript solely on the client (such as a Netscape browser). Larger-scale applications frequently have more complex needs, such as communicating with a relational database, providing continuity of information from one invocation to another of the application, or performing file manipulations on a server. For these more demanding situations, Netscape web servers contain server-side JavaScript, which has extra JavaScript objects to support server-side capabilities.

Some aspects of the core language act differently when run on a server. In addition, to support the increased performance demands in these situations, server-side JavaScript is compiled before installation, whereas the runtime engine compiles each client-side JavaScript script at runtime.

For information about server-side JavaScript, see the book Server-Side JavaScript Guide for iPlanet Web Server.

Enabling Server-Side JavaScript

To enable or disable server-side JavaScript, use the Server-Side JavaScript page in the Programs tab in the Server Manager interface.

When server-side JavaScript is enabled, the obj.conf file has the following directives:

Compiling Server-Side JavaScript Applications

Before you can deploy a server-side JavaScript application, you must compile it into a.web file. Several sample JavaScript applications, including the source files, the .web files, and the make files, are in the directory server-root/plugins/samples/js. One of the easiest ways to compile a new application is to copy a make file for an existing application and modify it to suit your needs.

For information about compiling server-side JavaScript Applications, see the section "Compiling an Application" in Chapter 3, "Mechanics of Developing JavaScript Applications," in the book Server-Side JavaScript Guide for iPlanet Web Server.

Installing Server-Side JavaScript Applications

After compiling the application, use the JavaScript Application Manager to register it with the iPlanet Web Server.

To access the JavaScript Manager in a browser, open the URL http://server_name/appmgr/, for example http://poppy.mcom.com/appmgr/.

To access the JavaScript Application Manager from the Server Manager interface, go to the Server-Side JavaScript page in the Programs tab. At the top of the page, you see a line such as:

The Server side Javascript Application Manager is at http://poppy.mcom.com/appmgr/
Click on the location for the application manager. The application manager opens in another browser window. You can use the application manager to add JavaScript applications, run them, stop them, start them, and debug them.

For information about using the JavaScript Application Manager, see:

For More Information

For information about JavaScript, you can view the following online books:

CGI

Common Gateway Interface (CGI) programs run on the server and generate a response to return to the requesting client. CGI programs can be written in various languages, including C, C++, Java, Perl, and as shell scripts. CGI programs are invoked through URL invocation.

iPlanet Web Server complies with the version 1.1 CGI specification.

Since the server starts up a process each time the CGI script or program runs, this is an expensive method of programming the server.

Enabling CGI

iPlanet Web Server provides two ways to identify CGI programs:

Specifying CGI Directories
To specify directories that contain CGI programs (and only CGI programs) use the CGI Directory page in the Programs tab of the Server Manager. The server treats all files in these directories as CGI programs.

For each CGI directory, the file obj.conf contains a NameTrans directive that associates the name cgi with each request for a resource in that directory. These directives are automatically added to obj.conf when you specify CGI directories in the Server Manager interface, or you can manually add them to obj.conf if desired.

For example, the following instruction interprets all requests for resources in http://server-name/cgi-local as requests to invoke CGI programs in the directory D:/Netscape/Server4/docs/mycgi.

NameTrans fn="pfx2dir" from="/cgi-local" dir="D:/Netscape/Server4/docs/mycgi" name="cgi"
The obj.conf file must contain the following named object:

<Object name="cgi">
ObjectType fn="force-type" type="magnus-internal/cgi"
Service fn="send-cgi"
</Object>
Do not remove this object from obj.conf. If you do, the server will never recognize CGI directories, regardless of whether you specify them in the Server Manager interface or manually add more NameTrans directives to obj.conf.

Specifying CGI File Extensions
Use the CGI File Type page in the Programs tab of the Server Manager to instruct the server to treat all files with certain extensions as CGI programs, regardless of which directory they reside in. The default CGI extensions are .cgi, .bat and.exe.

To change which extensions indicate CGI programs, modify the following line in mime.types to specify the desired extensions. Be sure to restart the server after editing mime.types.

type=magnus-internal/cgi exts=cgi,exe,bat
When the server is enabled to treat all files with an appropriate extensions as CGI programs, the obj.conf file contains the following Service directive:

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

Adding CGI Programs to the Server

To add CGI programs to the iPlanet Web Server, simply do one of the following:

Windows NT CGI and Shell CGI Programs

For information about installing CGI and shell CGI programs on Windows NT using the Server Manager interface, see Chapter 11, "Extending Your Server with Programs," of the iPlanet Web Server Administrator's Guide.

CGI Variables

In addition to the standard CGI variables, you can use the iPlanet Web Server CGI variables in Table 0.1 in CGI programs to access information about the client certificate if the server is running in secure mode. The CLIENT_CERT and REVOCATION variables are available only when client certificate based authentication is enabled.

Table 0.1 CGI Variables
Variable Description

SERVER_URL

The URL of the server that the client requested

HTTP_xxx

An incoming HTTP request header, where xxx is the name of the header

HTTPS

ON if the server is in secure mode and OFF otherwise

HTTPS_KEYSIZE

The keysize of the SSL handshake (available if the server is in secure mode)

HTTPS_SECRETKEYSIZE

The keysize of the secret part of the SSL handshake (available if the server is in secure mode)

HTTPS_SESSIONID

The session ID for the connection (available if the server is in secure mode)

CLIENT_CERT

The certificate that the client provided

CLIENT_CERT_SUBJECT_DN

The Distinguished Name of the subject of the client certificate

CLIENT_CERT_SUBJECT_OU

The Organization Unit of the subject of the client certificate

CLIENT_CERT_SUBJECT_O

The Organization of the subject of the client certificate

CLIENT_CERT_SUBJECT_C

The Country of the subject of the client certificate

CLIENT_CERT_SUBJECT_L

The Location of the subject of the client certificate

CLIENT_CERT_SUBJECT_ST

The State of the subject of the client certificate

CLIENT_CERT_SUBJECT_E

The E-mail of the subject of the client certificate

CLIENT_CERT_SUBJECT_UID

The UID part of the CN of the subject of the client certificate

CLIENT_CERT_ISSUER_DN

The Distinguished Name of the issuer of the client certificate

CLIENT_CERT_ISSUER_OU

The Organization Unit of the issuer of the client certificate

CLIENT_CERT_ISSUER_O

The Organization of the issuer of the client certificate

CLIENT_CERT_ISSUER_C

The Country of the issuer of the client certificate

CLIENT_CERT_ISSUER_L

The Location of the issuer of the client certificate

CLIENT_CERT_ISSUER_ST

The State of the issuer of the client certificate

CLIENT_CERT_ISSUER_E

The E-mail of the issuer of the client certificate

CLIENT_CERT_ISSUER_UID

The UID part of the CN of the issuer of the client certificate

CLIENT_CERT_VALIDITY_START

The start date of the certificate

CLIENT_CERT_VALIDITY_EXIRES

The expiration date of the certificate

CLIENT_CERT_EXTENSION_xxx

The certificate extension, where xxx is the name of the extension

REVOCATION_METHOD

The name of the certificate revocation method if it exists

REVOCATION_STATUS

The status of certificate revocation if it exists

For More Information

A myriad of information about writing CGI programs is available. A good starting point is "The Common Gateway Interface" at:

http://hoohoo.ncsa.uiuc.edu/cgi/overview.html

Java Servlets and JavaServer Pages (JSP)

iPlanet Web Server 4.1 supports Java servlets and JavaServer Pages (JSP). The server supports Java Servlets API 2.2.1 and JSP API Level 1.1.

Java servlets are server-side Java programs that can be used to generate dynamic content in response to client requests in much the same way as CGI programs do. Servlets are invoked through URL invocation.

You create servlets using the Servlets API, which was created by Sun Microsystems. iPlanet Web Server 4.1 includes all the files necessary for developing and running Java Servlets. You can compile servlets using any Java compiler you like, so long as the servlets.jar file is accessible to your Java compiler. The servlets.jar file is in the server installation directory at:

/bin/https/jar
For information about using the Servlet API, see the Java Servlet API documentation from Sun Microsystems at:

http://java.sun.com/products/servlet/index.html
A JavaServer Page (JSP) is a page much like an HTML page that can be viewed in a web browser. However, in addition to HTML tags, it can include a set of JSP tags that extend the ability of the web page designer to incorporate dynamic content in a page. These tags provide functionality such as displaying property values and using simple conditionals.

For more information on using JavaServer Pages, see the JavaServer Pages documentation from Sun Microsystems at:

http://java.sun.com/products/jsp/index.html

Enabling Java Servlets and JavaServer Pages

When you install iPlanet Web Server 4.1, you can choose to install the Java Runtime Environment (JRE) or you can specify a path to the Java Development Kit (JDK).

The server can run servlets using the JRE, but it needs the JDK to run JSP. The JDK is not bundled with the iPlanet Web Server, but you can download it for free from Sun Microsystems at:

http://java.sun.com/products/jdk/1.2/
iPlanet Web Server 4.1 requires you to use an official version of JDK 1.2. For details, see the Programmer's Guide to Servlets for iPlanet Web Server.

Regardless of whether you choose to install the JRE or specify a path to the JDK during installation, you can tell the iPlanet Web Server to switch to using either the JRE or JDK at any time by using the "Configure JRE/JDK Paths" page in the Servlets tab of the Server Manager.

Before the server can serve servlets and JSP, the servlet engine must be enabled. To enable servlets and JSP, use the Enable/Disable Servlets/JSP page in the Servlets tab of the Server Manager interface. If servlets are enabled, JSP can be enabled or disabled. If servlets are disabled, JSP is also disabled.

When servlets are enabled, the obj.conf file contains the following Init directives. The first one loads the servlets library and makes the servlet-related functions available to the iPlanet Web Server. The other two directives initialize the servlet engine. The shlib value shown is for Windows NT.

Init shlib="d:/server_root/bin/https/bin/NSServletPlugin.dll" funcs="NSServletEarlyInit,NSServletLateInit,NSServletNameTrans,NSServletService" shlib_flags="(global|now)" fn="load-modules"
Init EarlyInit="yes" fn="NSServletEarlyInit"
Init LateInit="yes" fn="NSServletLateInit"
For Unix, the shlib value is as follows:

shlib="server_root/bin/https/lib/libNSServletPlugin.so"
The file obj.conf also has other directives that relate to servlets, and defines several additional objects for processing requests for servlets.

Adding Servlets and JavaServer Pages to the Server

There are two ways to make a servlet accessible to clients once servlet activation has been enabled:

To add a JSP 1.x file to the server, simply give the file a .jsp extension, and put it on the server in a directory at or below the document root. So long as JSP is enabled, the iPlanet Web Server treats all files with a .jsp extension as JavaServer Pages.

To add a JSP 0.92 file to the server, you must place the file in a legacy directory.

NOTE: Do not put JSP files in a registered servlets directory, since the iPlanet Web Server expects all files in a registered servlet directory to be servlets.

For More Information

For more information about using servlets in iPlanet Web Server 4.1, see the book Programmer's Guide to Servlets for iPlanet Web Server.

For more information about using the Servlets API to create servlets, see the Java Servlet API documentation from Sun Microsystems at:

http://java.sun.com/products/servlet/index.html
For information about creating JSPs, see Sun Microsystem's JavaServer Pages web site at:

http://java.sun.com/products/jsp/index.html

NSAPI

Netscape Server Application Programming Interface (NSAPI) is a set of C functions for implementing extensions to the server. These extensions are known as server plugins.

Using NSAPI, you can write plugins to extend the functionality of the iPlanet Web Server. An NSAPI plugin defines one or more Server Application Functions (SAFs). You can develop SAFs for implementing custom authorization, custom logging, or for other ways of modifying how the iPlanet Web Server handles requests.

The file obj.conf contains instructions (known as directives) that tell the server how to process requests received from clients. Each instruction is enacted either during server initialization or during a particular stage of the request-handling process. Each instruction invokes a server application function (SAF).

For example, the following instruction is invoked when the request method is GET and the requested resource is of type text/html. This instruction calls the append-trailer function with a trailer argument of <H4><font color=green>Served by 4.0</font></H4>. (The append-trailer function simply returns the requested resource -- in this case an HTML file -- to the client, and appends the given trailer to it.)

Service method=GET type="text/html" fn=append-trailer trailer="<H4><font color=green>Served by 4.0</font></H4>" 
iPlanet Web Server 4.1 comes with a set of pre-defined SAFs. It also comes with a library of NSAPI functions for developing your own SAFs to modify the way that the server handles requests.

Enabling NSAPI

You don't enable NSAPI as such. You use it to develop server application functions (SAFs) to use in the file obj.conf. The file obj.conf is essential for the operation of the server -- if it does not exist, the server cannot work, since it has nowhere to look for instructions on how to handle requests.

When defining new SAFs, include the header function nsapi.h (which is in server_root/plugins/include) to get access to all the NSAPI functions.

Installing NSAPI Plugins (SAFs)

To load new NSAPI plugins containing customized SAFs into the server, add an Init directive to obj.conf to load the shared library file that defines the new SAFs. This directive must call the load-modules function, which takes the following arguments:

For example, the following directive loads the shared library d:/netscape/server4/bin/https/bin/httpdlw.dll, (which enables server-side JavaScript) and makes the functions livewireInit, livewireNameTrans, and livewireService available to the server.

Init fn="load-modules" shlib="d:/netscape/server4/bin/https/bin/httpdlw.dll" funcs="livewireInit,livewireNameTrans,livewireService"

For More Information

For information about changes to NSAPI in iPlanet Web Server 4.1, see Chapter 4, "NSAPI Changes."

For information about the following topics, see the NSAPI Programmer's Guide for iPlanet Web Server.

Web Application Interface (WAI) API

WAI is supported in iPlanet Web Server 4.1, but is not guaranteed to be supported in future releases.

Using the Web Application Interface (WAI) API, you can write C, C++, and Java applications that process HTTP requests sent to the server. A WAI application runs within its own process. The iPlanet Web Server interacts with your application over Internet Inter-ORB Protocol (IIOP).

WAI is a CORBA-based programming interface. WAI defines object interfaces to the HTTP request/response data and to server information. Using WAI, you can write a web application in C, C++, or Java that accepts an HTTP request from a client, processes it, and returns a response to the client. You can also write your own server plugins for processing HTTP requests.

For more information about writing applications in WAI, see the online manual Writing Web Applications with WAI.

Enabling WAI

Before installing the WAI component of your iPlanet Web Server 4.1, you need to install Visibroker 3.3 or higher from Inprise. For information about Visibroker, see:

   http://www.inprise.com/visibroker/
After installing Visibroker, install the WAI component of iPlanet Web Server 4.1. After WAI is installed, you then need to enable WAI. Do this by using the WAI Management page in the Programs tab of the Server Manager. (If WAI is not installed, this button does not appear.)

Installing WAI Applications

You install a WAI application in the same way that you install other NSAPI plugins. The application must contain an initialization function that registers the application. You load it into the server in the usual manner, by adding the following directives to obj.conf:

Start your application on the host machine that runs the iPlanet Web Server. Make sure that when the initialization function registers the application, it specifies the host name and port of the iPlanet Web Server.

Note that it is possible (but not recommended) to run WAI applications on other machines in the local network. For a complete explanation of the security concerns and instructions for configuring the server to recognize WAI applications on other machines, see Chapter 8, "Security Guidelines for Using WAI," in the online manual Writing Web Applications with WAI.

For More Information

For more information about Visibroker from Inprise, see:

http://www.inprise.com/visibroker/
For more information about writing WAI applications, see:

http://www.iplanet.com/docs/

Access Control API

The Access Control API is a C API that lets you programmatically control who has access to what on the iPlanet Web Server.

Access control lists (ACLs) determine who has what kind of access privileges to which resources on the server. Each ACL contains a list of access control entries. The following access control entry, for example, says that all access is denied to everyone for any resource that contains the substring private.

acl "*private*";
deny (all)
(user = "anyone");
To create access control lists, use the Restrict Access page in the Programs tab of the Server Manager interface. You can also edit the files that contain the ACLs used by the server.

Access control lists reside in the directory server_installation_dir/httpacl. The server uses the default settings in the file server_root/httpacl/generated.https-serverid.acl. There is also a file called genwork.https-serverid.acl that is a working copy the server uses until you save and apply your changes when working with the user interface. When editing the ACL file, you might want to work in the genwork file and then use the Server Manager to load and apply the changes.

With the Access Control API, you can manipulate access control lists (ACLs), read and write ACL files, and evaluate and test access to resources on the server. You can also define your own attributes for authentication. For example, you might want to authenticate users based on email address or on the URL that referred them to the resource. You can also authenticate the client based on your own authentication methods and databases.

Registering New Authentication Services

To tell the server to use your attributes for authentication, you need to define your own Loadable Authentication Service (LAS), which is an NSAPI plugin. You load it into the server in the usual manner by adding the following directives to obj.conf:

For More Information

For information about using the ACL API, see the Access Control Programmer's Guide. For information about the syntax for editing ACL files, see Appendix A in the same book.

Web Publishing API

The Web Publishing API provides a set of Java classes that allow client Java applications and applets to manipulate resources, such as files and directories, on the server. With these classes, the client application can perform standard file system actions such as creating, deleting, and copying resources.

In addition, you can associate meta-information (attributes) with a resource to track arbitrary information about the resource, such as associating a project or a list of reviewers with the resource. You can use the locking facility to ensure that two users don't edit the same resource at the same time. You can also choose to track the history of a component resource by maintaining separate versions of it -- this is known as version control.

Enabling Web Publishing

To enable Web Publishing, use the Web Publishing State page in the Web Publishing tab of the Server Manager interface.

For More Information

For more information about using the Web Publishing Client API, see the Web Publishing Client API Guide.

API Summary

The following table lists the APIs available in iPlanet Web Server 4.1.

Table 0.2 APIs available in iPlanet Web Server 4.1
API/Interface/Protocol Language Documentation

Interfaces for Generating Dynamic Content

Custom Server-Parsed HTML Tags

C

Chapter 3, "Server-Parsed HTML Tags."

Server-Side JavaScript (LiveWire) and LiveConnect

JavaScript

JavaScript Reference and

Server-Side JavaScript Guide for iPlanet Web Server

Java Servlets

Java

Programmer's Guide to Servlets for iPlanet Web Server

JavaServer Pages

HTML with additional JSP tags

Programmer's Guide to Servlets for iPlanet Web Server

CGI (one process per request)

C, C++, Perl, shell, and other languages

The Common Gateway Interface

APIs for Writing Server Plugins

NSAPI (in-process shared object/DLL)

C, C++

NSAPI Programmer's Guide for iPlanet Web Server

WAI (separate process)

C, C++, Java

Writing Web Applications with WAI

Access Control API

C, C++

Access Control Programmer's Guide

API For Modifying Server Resources

Web Publishing Interface

Java

Web Publishing Client API Guide


Table of Contents | Previous | Next | Index | Bookshelf

Last Updated: 03/01/00 09:14:02

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