The C API functions fall into these categories, which are described in the sections that follow:
The AOLserver uses dynamically allocated memory extensively. To ease the burden of checking for memory-allocation failures, the AOLserver provides wrapper functions for the malloc family of memory allocation functions.
The AOLserver functions differ from their system counterparts: instead of returning NULL on memory-allocation failure, they instead attempt to recover automatically from a low-memory situation. The AOLserver attempts to recover by first freeing any memory from internal caches that can safely be flushed. If flushing caches fails to free enough memory, the AOLserver will wait 1 second and then, if necessary, another 10 seconds, in the hope that the memory shortage is temporary, perhaps caused by another program that will shortly stop executing. If the AOLserver cannot recover from a low-memory situation, it logs the failure and shuts down the server.
Using the AOLserver memory allocation functions is a matter replacing the corresponding malloc family system function with a function of the same name preceded by ns_. You can currently mix calls to the ns_ functions and their system counterparts. However, this is not recommended because the interface may change in future releases of AOLserver.
The memory allocation functions are listed below.
The AOLserver C API provides the following data structures for manipulating data common in HTTP connection requests and working with active HTTP connections.
An AOLserver C API function must often access data as sets of key-value pairs, for example:
The Ns_Set structure provides a convenient mechanism for manipulating key-value pairs of string data. The key-value pairs in an Ns_Set are Ns_SetFields (called "fields" for short). The Ns_SetField structure has the following definition:
typedef struct { char *name; /* Key name of field. */ char *value; /* Value of field (can be NULL) */ } Ns_SetField;
The Ns_Set structure has the following definition:
typedef struct { char *name; /* Name of set (can be NULL) */ int size; /* Current number of fields */ int maxSize; /* (used internally) */ Ns_SetField *fields; /* Array of Ns_SetField's */ } Ns_Set;
Within the Ns_Set, the fields are stored as an array, in the order in which the fields were added to the set. The array of fields grows dynamically as fields are entered.
To access the fields of a set, either use the lookup functions described below or loop through the fields directly as in the following code fragment:
for (n = 0; n < Ns_SetSize(set); ++n) { printf("field %d name: %s value: %s\n", n, Ns_SetKey(set, n), Ns_SetValue(set, n)); }
The functions that use the Ns_Set data structure are listed in the following table.
An AOLserver C API function often uses dynamically allocated strings. The Ns_DString structure is used for this purpose. (The AOLserver Ns_DString is based on the Tcl_DString found in the Tcl C API.) Ns_DStrings contains a small amount of static space but will overflow to allocated memory if needed. Within the AOLserver, pointers to Ns_DStrings are often used where other APIs would require a pointer to a buffer and a specific size.
The Ns_DString structure has the following definition:
typedef struct { char *string; /* Points to either static space or dynamically allocated memory */ int length; /* Number of bytes in string */ int spaceAvl; /* Number of bytes unused but allocated for string */ char staticspace [NS_DSTRING_STATIC_SIZE]; /* Initial static space. */ } Ns_DString;
NS_DSTRING_STATIC_SIZE is by default set to 512 bytes.
The functions that use the Ns_DString data structure are listed in the following table.
All functions that handle connection requests, which we refer to as AOLserver operations, take as an argument a pointer to an Ns_Conn structure. This structure contains all information and state about the active connection. The public members that you may find useful include:
typedef struct Ns_Conn {Ns_Request *request;
Pointer to an Ns_Request structure that holds information about the HTTP request associated with the connection. The Ns_Request structure is described below.
Ns_Set *headers;
Pointer to an Ns_Set whose fields are the HTTP request headers sent by the HTTP client.
Ns_Set *outputheaders;
Pointer to an Ns_Set whose fields are the headers to be sent to the client.
char *authUser;
Decoded user name from the header information. Because the AOLserver does not authenticate the user when world permission is allowed to a URL, this user may not be a valid AOLserver user.
char *authPasswd;
Decoded user password from the header information. Because the AOLserver does not authenticate the user when world permission is allowed to a URL, this password may not be the user's actual password.
int contentLength;
Number of bytes in the content sent by the HTTP client.
} Ns_Conn;
The Ns_Request structure breaks a complete HTTP request line into its many parts.
typedef struct Ns_Request {char *line;
A copy of the actual request line sent by the HTTP client.
char *method;
HTTP method; for example GET or POST.
char *protocol;
Protocol of the HTTP request, e.g., http or ftp. Normally, this element is NULL because the AOLserver does not currently proxy requests, so fully-qualified URLs in HTTP requests are rejected.
char *host;
Host part of the URL in the HTTP request. Normally this element is NULL because the AOLserver does not currently proxy HTTP requests.
unsigned short port;
Port explicitly specified in the URL of the HTTP request. This element is 0 when no port is explicitly specified.
char *url;
URL after having been normalized with Ns_NormalizePath() function and after removing any query data that may have been appended.
char *query;
Any query data appended to the URL. (Query data are any data that follow a question mark at the end of a URL. They can be used to pass arguments to an operation.)
int urlc;
Number of path elements in the normalized URL. This is similar to the argc parameter to the main() function in a C program. For example, if the URL were /some/url
, urlc would be 2.
char **urlv;
NULL-terminated array of pointers to strings for each path element of the normalized URL. This is similar to the argv parameter to the main() function in a C program. For example, if the URL was /some/url
, urlv[0] would be "some", urlv[1] would be "url", and urlv[2] would be NULL.
double version;
Version of the HTTP request, usually 0.9 or 1.0.
} Ns_Request;
The AOLserver provides several convenient functions for working with the elements of the Ns_Request structure. The functions that use the Ns_Request data structure are listed in the following table.
The groups of core functions listed below are described in the following subsections.
At startup time, the server loads your C module and runs your initialization function. Your initialization function can connect to any external data sources or initialize any data structures it requires. The initialization function then typically calls one or more of the following functions to register other functions within the module as capable of handling URL requests or implementing traces, chores, or shutdown procedures.
The functions in this category are listed in the following table.
The hierarchical access checking authorization system is accessed through the following functions.
Caching is managed with the following functions:
When the server is started, it reads the AOLserver configuration file into memory. You can use the following functions to access the in-memory representation of those data. See Chapter 4 in the AOLserver Administrator's Guide for more information on the AOLserver configuration file.
AOLserver operations often work with files within the pages directory. These files normally are related to URLs that are requested by clients. The AOLserver provides the following functions for converting URLs to files within the pages directory and testing the files for various properties.
Construct a path name relative to the AOLserver home directory | |
The C API includes the following functions to generate and send HTTP headers to a browser. If the original request was not HTTP version 1.0 or higher, these functions do not send the headers to the client. This allows you to write header generating code without regard to HTTP version.
The following functions can be used to generate complete responses to HTTP requests.
Return a short notice to a client to contact system administrator | |
Often the only response required by the AOLserver is the HTTP status line. For example, after a successful PUT of a new file, the only required response is the status line to indicate if the file was successfully saved on the server. The following functions call Ns_ConnReturnStatus or Ns_ConnReturnNotice with the appropriate status code, reason, and/or notice message:
The following functions can be used to send data directly to the client. No formatting or immediate buffering is done to the data.
The functions in this category are listed in the following table.
The functions in this category are listed in the following table:
The functions in this category are listed in the following table.
The functions in this category are listed in the following table.
These functions allow you to specify a procedure to be run daily, weekly, or at specified intervals
Schedule a procedure to run at specified intervals (simplified options) | |
Schedule a procedure to run at specified intervals (expanded options) | |
The following functions are available for managing sockets. Developers should consult a book on socket programming when using these functions, for example "Unix Network Programming" by W. Richard Stevens.
The functions in this category are listed in the following table:
The functions in this category are listed in the following table. In rows where more than one function is listed, the preferred function is listed first.
Condition variables are managed with the following functions
Semaphores are managed with the following functions. The preferred function is listed first in each row.
Mutexes are managed with the following functions. The preferred function is listed first in each row.
Events are managed with the following functions:
Critical sections are managed with the following functions. The preferred function is listed first in each row.
Read/write locks are managed with the following functions. The preferred function is listed first in each row.
The following functions are used to support platform independent multithreaded programming. A table following this list of functions points you to further information for each function.
Put the current thread to sleep momentarily, allowing other threads to run, | |
The following table tells you what to look under in your vendor-specific documentation for more information on threaded programming with respect to each function.
(2) Threads on SGI Irix 5.3 are implemented as a process group with all attributes shared. As such, threads will show up as separate processes in a process listing using the ps command. Note, however, that although the server is implemented with multiple processes, it is still multithreaded in all respects (e.g., a single address space, open file table, etc.). In addition, if one process dies unexpectantly (e.g., core dump or on receiving a kill -9), the other processes will be notified and immediately exit. On Irix 6.2, you may run the 5.3 share group version (nsd binary) or a newer pthreads interface binary (nsdp).
(3) The pthread_join routine would allow multiple threads to wait for a single thread to exit on pthreads. However, in the nsthread library, only a single thread may wait using the Ns_ThreadJoin function.
(4) To allow any thread to wait for any other thread as in other multithreaded platforms, the SGI Irix threads interface uses a thread manager process which actually performs the sproc and waitpid calls on behalf of the other process threads.
(5) Pthreads does not include a semaphore and is emulated with a mutex and condition variable.
(6) SGI Irix does not include an event object and is emulated with ordinary process signals and the sigtimedwait and kill system calls.
(7) Nsthread events are emulated with pthread condition variables.
(10) Critical sections are emulated with a mutex and a condition variable.
(11) Thread local storage is not available on SGI sproc and is emulated using the PRDA, the process data area, as defined in the sys/prcnt.h header.
The following functions are used to manipulate Tcl interpreters.
The following are miscellaneous utility functions in the AOLserver C API.
Encrypt a password in the form used by the Unix /etc/passwd file and the nsperm module. | |
Return path name of the AOLserver pages directory for a server. | |
The AOLserver provides several functions for accessing the database. These include convenient routines for sending DML and DDL SQL statements or SQL statements that return rows from the database. (DML stands for Data Manipulation Language and includes SQL statements to insert, update, and delete data. DDL stands for Data Definition Language and includes SQL statements to create tables and views.)
There are also powerful catalog functions that help you build custom responses based on the schema of the tables within the database. These functions are only available if the nsdb module is loaded.
The following groups of database functions are described in the following subsections.
Functions used to obtain information about database pools and obtain handles to database pools. | |
Functions used to send queries to the database and process the results | |
The functions in this category are listed in the following table.
The AOLserver C Database API includes the following functions for sending queries to the database and processing the results. Rows are returned as Ns_Set structures described earlier.
Return an Ns_Set structure of columns returned by the previously-executed SQL command | |
The following functions handle stored procedures.
The following functions provide additional ways to manipulate the database.