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:
Write thread-safe code
Blocking can affect performance
Write small functions with parameters and configure them in obj.conf
Carefully check and handle all errors and log them so you can determine the source of problems and fix them
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.