Previous     Contents     Index     DocHome     Next     
iPlanet Web Server, Enterprise Edition Programmer's Guide



Chapter 1   Overview


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

  • generate dynamic content in response to client requests

  • modify and extend the behavior of the server

  • modify the content stored in the server

This chapter 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:



Configuration Files

You can configure iPlanet Web Server using the Server Manager and Class Manager interfaces, or by editing configuration files. Most of the configuration files are in the directory in the server_root/https-server_id/config directory. For example, if iPlanet Web Server is installed on a Windows NT machine in C:\iPlanet\Servers\, the configuration files for the server myserver.com are in:

C:\iPlanet\Servers\https-myserver.com\config

The main configuration files are magnus.conf, server.xml, obj.conf, and mime.types, but there are other configuration files as well. See Chapter 2 "Configuration Files," for an overview of configuration files.

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

For information about configuration file changes since iPlanet Web Server 4.x, see Appendix A "Configuration Changes Between iWS 4.x and 6.0."



iPlanet Web Server 6.0 APIs


This section summarizes the various APIs and programming technologies supported by iPlanet Web Server 6.0, discusses how to enable the functionality in iPlanet Web Server 6.0, 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:

  • Dynamically generating responses (or parts of responses) to requests. The APIs and programming approaches that fall in this category are:

  • Modifying the behavior of the server itself by implementing server plugins. Most server plugins are written using Netscape Server API (NSAPI). There are also specialized APIs for writing server plugins, such as the Access Control List API (ACLAPI) which is used for controlling access to server resources.

    The APIs for modifying server behavior are:

  • Modifying the content of the server, by adding, removing, or modifying resources and directories. To do this, use remote file manipulation.


Server-Parsed HTML Tags

iPlanet Web Server 6.0 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 Content Management tab of the Class 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 directive in magnus.conf that enables the parsing of server-side tags is as follows for Windows NT:

Init funcs="shtml_init,shtml_send" shlib="install_dir/bin/https/bin/Shtml.dll" NativeThread="no" fn="load-modules"

For Unix, the directive is the same except that the file is Shtml.so.

The directive in obj.conf that enables the parsing of server-side tags is:

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


For More Information

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


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 Class 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 Class 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 C:/iPlanet/Servers/docs/mycgi.

NameTrans fn="pfx2dir" from="/cgi-local" dir="C:/iPlanet/Servers/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 Class 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 Class 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"


Creating Custom Execution Environments for CGI Programs (Unix only)

Before you can create a custom execution environment, you must install the suid Cgistub and run it as root:

  1. Log in as the superuser.

    su

  2. Create the private directory for Cgistub:

    cd server_root/https-instance

    mkdir private

  3. Copy Cgistub to the private directory:

    cd private

    cp ../../bin/https/bin/Cgistub .

  4. Set the owner of private to the server user:

    chown user .

  5. Set the permissions on private:

    chmod 500 .

  6. Set the owner of Cgistub to root:

    chown root Cgistub

  7. Set the permissions on Cgistub:

    chmod 4711 Cgistub

  8. You can give each reference to the send-cgi SAF in obj.conf a user parameter. For example:

    Service fn="send-cgi" user="user"

    You can use variable substitution. For example, in server.xml, give a VS (virtual server) element the following VARS subelement:

    <VARS user="user"/>

    This lets you write the send-cgi SAF line in obj.conf as follows:

    Service fn="send-cgi" user="$user"

    For more information about send-cgi, server.xml, and obj.conf, see the NSAPI Programmer's Guide for iPlanet Web Server.

  9. Restart the server so these changes take effect.


Note Installing Cgistub in the server_root/https-instance/private directory is recommended. If you install it anywhere else, you must specify the path to Cgistub in the init-cgi function in magnus.conf. For details, see the NSAPI Programmer's Guide for iPlanet Web Server.



Note It may not be possible to install the suid Cgistub program on an NFS mount. If you wish to use an suid Cgistub, you must install your server instance to a local file system.


Cgistub enforces the following security restrictions:

  • The user the CGI program executes as must have a uid of 100 or greater. This prevents anyone from using Cgistub to obtain root access.

  • The CGI program must be owned by the user it is executed as and must not be writable by anyone other than its owner. This makes it difficult for anyone to covertly inject and then remotely execute programs.

  • Cgistub creates its Unix listen socket with 0700 permissions.


    Note Socket permissions are not respected on a number of Unix variants, including current versions of SunOS/Solaris. To prevent a malicious user from exploiting Cgistub, change the server's temporary directory (using the magnus.conf TempDir directive) to a directory accessible only to the server user. For details, see the NSAPI Programmer's Guide for iPlanet Web Server.


After you have installed Cgistub, you can create custom execution environments in the following ways:


Specifying a Unique CGI Directory and Unix User and Group for a Virtual Server
To prevent a virtual server's CGI programs from interfering with other users, these programs should be stored in a unique directory and execute with the permissions of a unique Unix user and group.

First, create the Unix user and group. The exact steps required to create a user and group vary by operating system. For help, consult your operating system's documentation.

Next, follow these steps to create a cgi-bin directory for the virtual server:

  1. Log in as the superuser.

    su

  2. Change to the virtual server directory.

    cd vs_dir

  3. Create the cgi-bin directory.

    mkdir cgi-bin

    chown user:group cgi-bin

    chmod 755 cgi-bin

Now you can set the virtual server's CGI directory, user, and group in one of these ways:


Specifying a Chroot Directory for a Virtual Server
To further improve security, these CGI scripts should be prevented from accessing data above and outside of the virtual server directory.

First, set up the chroot environment. The exact steps required to set up the chroot environment vary by operating system. For help, consult your operating system's documentation. The man pages for ftpd and chroot are often a good place to start.

These are the steps required for Solaris versions 2.6 through 8:

  1. Log in as the superuser.

    su

  2. Change to the chroot directory. This is typically the vs_dir directory mentioned in the previous section.

    cd chroot

  3. Create tmp in the chroot directory:

    mkdir tmp

    chmod 1777 tmp

  4. Create dev in the chroot directory:

    mkdir dev

    chmod 755 dev

  5. List /dev/tcp, and note the major and minor numbers of the resulting output. In this example, the major number is 11 and the minor number is 42:

    ls -lL /dev/tcp

    crw-rw-rw- 1 root sys 11, 42 Apr 9 1998 /dev/tcp

  6. Create the tcp device using the major and minor numbers:

    mknod dev/tcp c 11 42

    chmod 666 dev/tcp

  7. Repeat steps 5 and 6 for each of the following devices (each device will have a different major and minor combination):

    /dev/udp
    /dev/ip
    /dev/kmem
    /dev/kstat
    /dev/ksyms
    /dev/mem
    /dev/null
    /dev/stderr
    /dev/stdin
    /dev/stdout
    /dev/ticotsord
    /dev/zero

  8. Set permissions on the devices in dev in the chroot directory:

    chmod 666 dev/*

  9. Create and populate lib and usr/lib in the chroot directory:

    mkdir usr

    mkdir usr/lib

    ln -s /usr/lib

    ln /usr/lib/* usr/lib

    You can ignore the messages this command generates.

    If the /usr/lib directory is on a different file system, replace the last command with the following:

    cp -rf /usr/lib/* usr/lib

  10. Create and populate bin and usr/bin in the chroot directory:

    mkdir usr/bin

    ln -s /usr/bin

    ln /usr/bin/* usr/bin

    You can ignore the messages this command generates.

    If the /usr/bin directory is on a different file system, replace the last command with the following:

    cp -rf /usr/bin/* usr/bin

  11. Create and populate etc in the chroot directory:

    mkdir etc

    ln /etc/passwd /etc/group /etc/netconfig etc

  12. Test the chroot environment:

    chroot chroot bin/ls -l

    The output should look something like this:

       total 14
       lrwxrwxrwx            1 root         other         8 Jan 13 03:32 bin -> /usr/bin
       drwxr-xr-x            2 user         group         512 Jan 13 03:42 cgi-bin
       drwxr-xr-x            2 root         other         512 Jan 13 03:28 dev
       drwxr-xr-x            2 user         group         512 Jan 13 03:26 docs
       drwxr-xr-x            2 root         other         512 Jan 13 03:33 etc
       lrwxrwxrwx            1 root         other         8 Jan 13 03:30 lib -> /usr/lib
       drwxr-xr-x            4 root         other         512 Jan 13 03:32 usr

Now you can set the virtual server's chroot directory in one of these ways:


Adding CGI Programs to the Server

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

  • Drop the program file in a CGI directory (if there are any).

  • Give it a file name that the server recognizes as a CGI program and put it in any directory at or below the document root (if CGI file type recognition has been activated).

For Unix, make sure the program file has execute permissions set.


Windows NT CGI and Shell CGI Programs

For information about installing CGI and shell CGI programs on Windows NT using the Class Manager interface, see the iPlanet Web Server Administrator's Guide.


Perl CGI Programs

You cannot run CGIs using Perl 5.6.x with the -w flag. Instead, include the following code in the file:

use warnings;


CGI Variables

In addition to the standard CGI variables, you can use the iPlanet Web Server CGI variables in Table 1-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 1-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 (binary DER format)  

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 6.0 supports the Java Servlet Specification version 2.2 (including Web Application and WAR file support) and the JavaServer Pages (JSP) Specification version 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 accessed through URL invocation.

You create servlets using the Servlets API, which was created by Sun Microsystems. iPlanet Web Server 6.0 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 servlet.jar file is accessible to your Java compiler. The servlet.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 and directives intermixed with Java code that extend the ability of the web page designer to incorporate dynamic content in a page. These additional features 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

To enable servlets, select the Java tab in the Server manager, then select the Enable/Disable Servlets/JSP tab. Check the Enable Java Globally box to enable servlets for the entire server. Check the Enable Java for Class box to enable servlets for a single virtual server class. You cannot enable servlets for a class unless Java is globally enabled. By default, Java is globally enabled and enabled for each virtual server class.

To enable JSPs, you must also include the jsp-servlet element with enable=true in the web-apps.xml file and add tools.jar to the JVM classpath. If you want to run uncompiled JSPs, you must also install the Java Development Kit (JDK).

When you install iPlanet Web Server 6.0, you can choose to install the Java Runtime Environment (JRE), which is provided with iPlanet Web Server, or you can specify a path to a JDK. 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/

The server can run servlets and precompiled JSPs using the JRE, but it needs the JDK to run uncompiled JSPs.

iPlanet Web Server 6.0 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 Global Settings tab of the Administration Server.

The magnus.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,N SServletService" 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

You can make servlets and JSPs accessible to clients in one of these two ways:

  • Include the servlets in web applications and deploy those web applications.

  • Configure the servlets in the default virtual server. This is provided for backward compatibility with iPlanet Web Server 4.x.

For more information, see the Programmer's Guide to Servlets for iPlanet Web Server.


For More Information

For more information about using servlets in iPlanet Web Server 6.0, 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 6.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 6.0</font></H4>"

iPlanet Web Server 6.0 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 magnus.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:

  • shlib -- the shared library to load.

  • funcs -- the functions to be made available to the server.


For More Information

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

  • the directives in obj.conf and how they determine how the server handles requests

  • the pre-defined SAFs that ship with iPlanet Web Server 6.0

  • the NSAPI functions available for writing custom SAFs

  • how to write custom SAFs

  • how to load custom SAFs into the iPlanet Web Server by adding an Init directive to magnus.conf that calls load-modules


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 having a URI that starts with /private.

acl "uri=/private/*";
deny (all)
(user = "anyone");

To create access control lists, use the Restrict Access page in the Preferences tab of the Server Manager interface. You can also edit the files that contain the ACLs used by the server.

The default access control list resides in the directory server_root/httpacl. The default ACL file is generated.https-server_id.acl. There is also a file called genwork.https-server_id.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 iPlanet Web Server 6.0, you can configure and reference multiple ACL files. For more information, see the discussion of the server.xml file in the NSAPI Programmer's Guide for iPlanet Web Server.

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. For example:

allow (read) referer="*www.acme.com*"

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 magnus.conf:

  • An Init directive that invokes the load-modules function to load the shared library.

  • An Init directive that calls the initialization function.


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.

For more information about configuring ACL files for virtual servers, see the discussion of the server.xml file in the NSAPI Programmer's Guide for iPlanet Web Server.

For information about changes to the access control API in iPlanet Web Server 6.0, see the comments in the server_root/plugins/include/nsacl/aclapi.h file.


Certificate-Mapping API

The Certificate-Mapping API consists of data structures and functions used to manage certificate mapping.

When a user authenticates to an iPlanet server by sending a client certificate to the server, the server uses information in the certificate to search the user directory for the user's entry.

You can configure some parts of this process by editing the file certmap.conf. This file specifies:

  • How the server searches the directory for the user's entry

  • Whether the server goes through an additional step of verifying that the user's certificate matches the certificate presented to the server

For more information about this file, see Chapter 2 "Configuration Files."

You can also modify this "certificate to directory entry" process programmatically. iPlanet servers include a set of API functions (referred to here as the Certificate-Mapping API functions) that allow you to control this process. You can write your own functions to customize how certificate subject entries are found in the directory.

To use this API, you need to have a copy of the Directory SDK. You can download a copy of this SDK from this site:

http://developer.iplanet.com/


For More Information

For information about using the certificate-mapping API, see the Certificate-Mapping Programmer's Guide.



API Summary


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

Table 1-2    APIs available in iPlanet Web Server 6.0

API/Interface/Protocol

Language

Documentation

Interfaces for Generating Dynamic Content

Custom Server-Parsed HTML Tags  

C  

Chapter 3 "Server-Parsed HTML Tags"  

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  

Access Control API  

C, C++  

Access Control Programmer's Guide  

Certificate-Mapping API  

C, C++  

Certificate-Mapping Programmer's Guide  



Changes from Previous Versions


Changes from previous versions of iPlanet Web Server are summarized in the following sections:

For specific information about configuration files, see Appendix A "Configuration Changes Between iWS 4.x and 6.0."


API Changes Since iPlanet Web Server 3.x

  • New API for defining customized server-parsed tags as NSAPI plugins has been added. For more information, see Chapter 3 "Server-Parsed HTML Tags."

  • Server side Java applets (HttpApplets) are not supported. Use Java servlets instead.

  • Agents API is not supported.

  • NSAPI has new features.


API Changes Since iPlanet Web Server 4.0

  • Java Servlets version 2.2.1 and JavaServer Pages 1.1 are supported.

  • HTTP/1.1 cookies are supported.

  • Descriptions of CGI variables have been added to the "CGI Variables" section in this chapter.

  • You can invoke servlets as SSI in HTML pages by using the <SERVLET> tag, as discussed in Chapter 3 "Server-Parsed HTML Tags."

  • NSAPI has new features.


API Changes Since iPlanet Web Server 4.1

  • Programs such as servlets modify a virtual server instead of the server as a whole. (To add programs as in iPlanet Web Server 4.1, you can configure only one virtual server.)

  • Web applications are now supported as described in the Java Servlet 2.2 API Specification.

  • NSAPI has new features. For details, see the NSAPI Programmer's Guide for iPlanet Web Server.

  • Some configuration files have changed. For details, see Appendix A "Configuration Changes Between iWS 4.x and 6.0."

  • The access control API has changed. For details, see the comments in the server_root/plugins/include/nsacl/aclapi.h file.


Previous     Contents     Index     DocHome     Next     
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2001 Netscape Communications Corp. All rights reserved.

Last Updated May 14, 2001