Oracle iPlanet Web Proxy Server 4.0.14 NSAPI Developer's Guide

Writing the Source Code

Write custom SAFs using NSAPI functions. For a summary of some of the most commonly used NSAPI functions, see Overview of NSAPI C Functions. For information about available routines, see Chapter 4, NSAPI Function Reference

For examples of custom SAFs, see nsapi/examples/ in the server root directory, and Chapter 3, Examples of Custom SAFs and Filters

The signature for all SAFs is:

int function(pblock *pb, Session *sn, Request *rq);

For more details on the parameters, see SAF Parameters.

Proxy Server runs as a multi-threaded single process. UNIX platforms uses two processes, a parent and a child, for historical reasons. The parent process performs some initialization and forks the child process. The child process performs further initialization and handles all of the HTTP requests.

Keep the following guidelines in mind when writing your SAF:

If necessary, write an initialization function that performs initialization tasks required by your new SAFs. The initialization function has the same signature as other SAFs:

int function(pblock *pb, Session *sn, Request *rq);

SAFs work by obtaining certain types of information from their parameters. In most cases, parameter block (pblock) data structures provide the fundamental storage mechanism for these parameters. A pblock maintains its data as a collection of name-value pairs. For a summary of the most commonly used functions for working with pblock structures, see Parameter Block Manipulation Routines.

A SAF, definition does not specifically state which directive it is written for. However, each SAF must be written for a specific directive such as AuthTrans, Service, and so on. A SAF must conform behavior consistent wit the directive for which it was written. For more details, see Required Behavior of SAFs for Each Directive.