This chapter describes how to write your own NSAPI plug-ins that define custom Server Application Functions (SAFs). Creating plug-ins enables you to modify or extend the built-in functionality of Proxy Server. For example, you can modify the server to handle user authorization in a special way or generate dynamic HTML pages based on information in a database.
This chapter contains the following sections:
Before writing custom SAFs, you should familiarize yourself with the request-handling process, as described in Oracle iPlanet Web Proxy Server 4.0.14 Configuration File Reference. Also, before writing a custom SAF, see whether a built-in SAF already accomplishes the tasks you have in mind.
For information about predefined SAFs used in the obj.conf file, see Oracle iPlanet Web Proxy Server 4.0.14 Configuration File Reference.
For a complete list of the NSAPI routines for implementing custom SAFs, see Chapter 4, NSAPI Function Reference
The NSAPI interface might change in a future version of Proxy Server. To keep your custom plug-ins upgradeable :
Make sure plug-in users know how to edit the configuration files such as magnus.conf and obj.conf manually. The plug-in installation software should not be used to edit these configuration files.
Keep the source code so you can recompile the plug-in.
All SAFs, both custom and built-in have the same C interface regardless of the request-handling step for which they are written. These small functions are designed for a specific purpose within a specific request-response step. They receive parameters from the directive that invokes them in the obj.conf file, from the server, and from previous SAFs.
int function(pblock *pb, Session *sn, Request *rq);
The SAF parameter section discusses the parameters in detail.
The SAF returns a result code that indicates whether and how it succeeded. The server uses the result code from each function to determine how to proceed with processing the request. See , for details of the result codes.
This section discusses the SAF parameters in detail. The parameters are:
pb (parameter block) — Contains the parameters from the directive that invokes the SAF in the obj.conf file.
sn (session) — Contains information relating to a single TCP/IP session.
rq (request) — Contains information relating to the current request.
The pb parameter is a pointer to a pblock data structure that contains values specified by the directive that invokes the SAF. A pblock data structure contains a series of name-value pairs.
The following example shows a directive that invokes the basic-nsca function:
AuthTrans fn=basic-ncsa auth-type=basic dbm=/<Install_Root> /<Instance_Directory>/userdb/rs |
In this case, the pb parameter passed to basic-ncsa contains name-value pairs that correspond to auth-type=basic and dbm=/<Install_Root>/<Instance_Directory>/userdb/rs.
NSAPI provides a set of functions for working with pblock data structures. For example, pblock_findval() returns the value for a given name in a pblock. See Parameter Block Manipulation Routines, for a summary of the most commonly used functions for working with parameter blocks.
The sn parameter is a pointer to a session data structure. This parameter contains variables related to an entire session, that is, the time between the opening and closing of the TCP/IP connection between the client and the server. The same sn pointer is passed to each SAF called within each request for an entire session. The following list describes the most important fields in this data structure see Chapter 4, NSAPI Function Reference for information about NSAPI routines for manipulating the session data structure.
Pointer to a pblock containing information about the client such as its IP address, DNS name, or certificate. If the client does not have a DNS name or if the name cannot be found, it will be set to -none.
Platform-independent client socket descriptor. This value is passed to the routines for reading from and writing to the client.
The rq parameter is a pointer to a request data structure. This parameter contains variables related to the current request, such as the request headers, URI, and local file system path. The same request pointer is passed to each SAF called in the request-response process for an HTTP request.
The following list describes the most important fields in this data structure. See Chapter 4, NSAPI Function Reference for information about NSAPI routines for manipulating the request data structure.
Pointer to a pblock containing the server’s working variables. This pblock includes anything not specifically found in the other three pblocks. The contents of this pblock vary depending on the specific request and the type of SAF. For example, an AuthTrans SAF might insert an auth-user parameter into rq->vars that can be used subsequently by a PathCheck SAF.
Pointer to a pblock containing elements of the HTTP request. This pblock includes the HTTP method (GET, POST, and so on), the URI, the protocol (normally HTTP/1.0), and the query string. This pblock does not normally change throughout the request-response process.
While obtaining the query string associated with a request, the query string is stored in reqpb pblock of the request structure only if the request URL is relative. If the request URL is absolute, the query string is not separated.
Pointer to a pblock containing all of the request headers, such as User-Agent, If-Modified-Since, and so on, received from the client in the HTTP request. See Chapter 8, Hypertext Transfer Protocol for more information about request headers. This pblock does not normally change throughout the request-response process.
Pointer to a pblock containing the response headers, such as Server, Date, Content-Type, Content-Length, and so on, to be sent to the client in the HTTP response. See Chapter 8, Hypertext Transfer Protocol for more information about response headers.
The rq parameter is the primary mechanism for passing information throughout the request-response process. On input to a SAF, rq contains the values that were inserted or modified by previously executed SAFs. On output, rq contains any modifications or additional information inserted by the SAF. Some SAFs depend on the existence of specific information provided at an earlier step in the process. For example, a PathCheck SAF retrieves values in rq->vars that were previously inserted by an AuthTrans SAF.
Upon completion, a SAF returns a result code. The result code indicates what the server should do next. The result codes are:
Indicates that the SAF achieved its objective. For some request-response steps (AuthTrans, NameTrans, Service, and Error), this result code tells the server to proceed to the next request-response step, skipping any other SAFs in the current step. For the other request-response steps (PathCheck, ObjectType, and AddLog), the server proceeds to the next SAF in the current step.
Indicates that the SAF took no action. The server continues with the next SAF in the current server step.
Indicates that an error occurred and an HTTP response should be sent to the client to indicate the cause of the error. A SAF returning REQ_ABORTED should also set the HTTP response status code. If the server finds an Error directive matching the status code or reason phrase, it executes the SAF specified. If no directive is found, the server sends a default HTTP response with the status code and reason phrase plus a short HTML page reflecting the status code and reason phrase for the user. The server then goes to the first AddLog directive.
Indicates that the connection to the client was lost. This result code should be returned when the SAF fails in reading or writing to the client. The server then goes to the first AddLog directive.
Custom SAFs are functions in shared libraries that are loaded and called by the server.
Writing the Source Code using the NSAPI functions. Each SAF is written for a specific directive.
Compiling and Linking the source code to create a shared library (.so, .sl, or .dll) file.
Loading and Initializing the SAF by editing the magnus.conf file to perform the following actions:
Instructing the Server to Call the SAFs by editing obj.conf to call your custom SAFs at the appropriate time.
Testing the SAF by accessing your server from a browser with a URL that triggers your function.
The following sections describe these steps in greater detail.
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.
Compile and link your code with the native compiler for the target platform. For UNIX, use the gmake command. For Windows, use the nmake command. For Windows, use Microsoft Visual C++ 6.0 or newer. You must have an import list that specifies all global variables and functions to access from the server binary. Use the correct compiler and linker flags for your platform. Refer to the example Makefile in the server_root/plugins/nsapi/examples directory.
This section provides following guidelines for compiling and linking.
Add the server_root/plugins/include (UNIX) or server_root\\plugins\\include (Windows) directory to your makefile to include the nsapi.h file.
Add the server_root/bin/https/lib (UNIX) or server_root\\bin\\https\\bin (Windows) library directory to your linker command.
The following table lists the relevant libraries.
Table 1–1 Linker Libraries
Platform |
Library |
---|---|
Windows |
ns-httpd40.dll (in addition to the standard Windows libraries) |
HP-UX |
libns-httpd40.sl |
All other UNIX platforms |
libns-httpd40.so |
To generate a shared library, use the commands and options listed in the following table.
Table 1–2 Linker Commands and Options
Platform |
Options |
---|---|
SolarisTM Operating System (SPARC® Platform Edition) |
ld -G or cc -G |
Windows |
link -LD |
HP-UX |
cc +Z -b -Wl,+s -Wl,-B,symbolic |
AIX |
cc -p 0 -berok -blibpath:$(LD_RPATH) |
Compaq |
cc -shared |
Linux |
gcc -shared |
IRIX |
cc -shared |
Use the linker flags in the following table to specify which directories should be searched for shared objects during runtime to resolve symbols.
Table 1–3 Linker Flags
Platform |
Flags |
---|---|
Solaris SPARC |
-R dir:dir |
Windows |
no flags, but the ns-httpd40.dll file must be in the system PATH variable |
HP-UX |
-Wl,+b,dir,dir |
AIX |
-blibpath:dir:dir |
Compaq |
-rpath dir:dir |
Linux |
-Wl,-rpath,dir:dir |
IRIX |
-Wl,-rpath,dir:dir |
On UNIX, you can also set the library search path using the LD_LIBRARY_PATH environment variable, which must be set when you start the server.
The following table lists the flags and defines you need to use for compilation of your source code.
Table 1–4 Compiler Flags and Defines
Parameter |
Description |
---|---|
Solaris SPARC |
-DXP_UNIX -D_REENTRANT -KPIC -DSOLARIS |
Windows |
-DXP_WIN32 -DWIN32 /MD |
HP-UX |
-DXP_UNIX -D_REENTRANT -DHPUX |
AIX |
-DXP_UNIX -D_REENTRANT -DAIX $(DEBUG) |
Compaq |
-DXP_UNIX -KPIC |
Linux |
-DLINUX -D_REENTRANT -fPIC |
IRIX |
-o32 -exceptions -DXP_UNIX -KPIC |
All platforms |
-MCC_HTTPD -NET_SSL |
The following table lists the optional flags and defines you can use.
Table 1–5 Optional Flags and Defines
Flag/Define |
Platforms |
Description |
---|---|---|
-DSPAPI20 |
All |
Needed for the proxy utilities function include file putil.h |
For each shared library (plug-in) containing custom SAFs to be loaded into Proxy Server, add an Init directive that invokes the load-modules SAF to obj.conf.
The syntax for a directive that calls load-modules is:
Init fn=load-modules shlib=[path]sharedlibname funcs="SAF1,...,SAFn"
shlib is the local file system path to the shared library (plug-in).
funcs is a comma-separated list of function names to be loaded from the shared library. Function names are case sensitive. You may use dash a (-) in place of an underscore (_) in function names. do not include spaces in the function name list.
If the new SAFs require initialization, be sure that the initialization function is included in the funcs list.
For example, if you created a shared library animations.so that defines two SAFs do_small_anim() and do_big_anim() and also defines the initialization function init_my_animations, you would add the following directive to load the plug-in:
Init fn=load-modules shlib=animations.so funcs="do_small_anim,do_big_anim, init_my_animations" |
If necessary, also add an Init directive that calls the initialization function for the newly loaded plug-in. For example, if you defined the function init_my_new_SAF() to perform an operation on the maxAnimLoop parameter, you would add a directive such as the following to magnus.conf:
Init fn=init_my_animations maxAnimLoop=5
Next, add directives to obj.conf to instruct the server to call each custom SAF at the appropriate time. The syntax for directives is:
Directive fn=function-name [name1="value1"]...[nameN="valueN"]
Directive is one of the server directives, such as AuthTrans, Service, and so on.
function-name is the name of the SAF to execute.
nameN="valueN" are the names and values of parameters which are passed to the SAF.
Depending on what your new SAF does, you might need to add just one directive to obj.conf, or you might need to add more than one directive to provide complete instructions for invoking the new SAF.
For example, if you define a new AuthTrans or PathCheck SAF, you could just add an appropriate directive in the default object. However, if you define a new Service SAF to be invoked only when the requested resource is in a particular directory or has a new kind of file extension, you would need to take extra steps.
If your new Service SAF is to be invoked only when the requested resource has a new kind of file extension, you might need to add an entry to the MIME types file so that the type value is set properly during the ObjectType stage. Then you could add a Service directive to the default object that specifies the desired type value.
If your new Service SAF is to be invoked only when the requested resource is in a particular directory, you might need to define a NameTrans directive that generates a name or ppath value that matches another object. Then, in the new object, you could invoke the new Service function.
For example, suppose your plug-in defines two new SAFs, do_small_anim() and do_big_anim(), which both take speed parameters. These functions run animations. All files to be treated as small animations reside in the directory D:/<Install_Root>/<Instance_Directory>/docs/animations/small, while all files to be treated as full-screen animations reside in the directory D:/<Install_Root>/<Instance_Directory>/docs/animations/fullscreen.
To ensure that the new animation functions are invoked whenever a client sends a request for either a small or full-screen animation, you would add NameTrans directives to the default object to translate the appropriate URLs to the corresponding path names and also assign a name to the request.
NameTrans fn=pfx2dir from="/animations/small" dir="/<Install_Root>/<Instance_Directory>/docs/animations/small" name="small_anim" NameTrans fn=pfx2dir from="/animations/fullscreen" dir="<Install_Root>/<Instance_Directory>docs/animations/fullscreen" name="fullscreen_anim" |
You also need to define objects that contain the Service directives that run the animations and specify the speed parameter.
<Object name="small_anim"> Service fn=do_small_anim speed=40 </Object> <Object name="fullscreen_anim"> Service fn=do_big_anim speed=20 </Object> |
After modifying obj.conf, you need to restart the server. A restart is required for all plug-ins that implement SAFs or filters.
Test your SAF by accessing your server from a browser with a URL that triggers your function. For example, if your new SAF is triggered by requests to resources in http://server-name/animations/small, try requesting a valid resource that starts with that URI.
You should disable caching in your browser so that the server is sure to be accessed. In Netscape NavigatorTM, Press the Shift key while clicking the Reload button to ensure that the cache is not used. If the images are already in the cache, this action does not always force the client to fetch images from the source.
You might also want to disable the server cache using the cache-init SAF.
Examine the access log and error log to help with debugging.
NSAPI provides a set of C functions that are used to implement SAFs. These functions serve several purposes; They provide platform independence across Proxy Server operating system and hardware platforms. They provide improved performance. They are thread-safe which is a requirement for SAFs. They prevent memory leaks. And they provide functionality necessary for implementing SAFs. You should always use these NSAPI routines when defining new SAFs.
This section provides an overview of the function categories available and some of the more commonly used routines. All of the public routines are described in detail in Chapter 4, NSAPI Function Reference
The main categories of NSAPI functions are:
The parameter block manipulation functions provide routines for locating, adding, and removing entries in a pblock data structure
pblock_findval returns the value for a given name in a pblock.
pblock_nvinsert adds a new name-value entry to a pblock.
pblock_remove removes a pblock entry by name from a pblock. The entry is not disposed. Use param_free to free the memory used by the entry.
param_free frees the memory for the given pblock entry.
pblock_pblock2str creates a new string containing all of the name-value pairs from a pblock in the form “name=value name=value.” This string can be useful for debugging.
Protocol utilities provide functionality necessary to implement Service SAFs
request_header returns the value for a given request header name, reading the headers if necessary. This function must be used when requesting entries from the browser header pblock (rq->headers).
protocol_status sets the HTTP response status code and reason phrase.
protocol_start_response sends the HTTP response and all HTTP headers to the browser.
Memory management routines provide fast, platform-independent versions of the standard memory management routines. These routines also prevent memory leaks by allocating from a temporary memory, called “pooled” memory for each request, and then disposing the entire pool after each request. There are wrappers for standard memory routines for using permanent memory.
The file I/O functions provide platform-independent, thread-safe file I/O routines.
system_fopenRO opens a file for read-only access.
system_fopenRW opens a file for read-write access, creating the file if necessary.
system_fopenWA opens a file for write-append access, creating the file if necessary.
system_fclose closes a file.
system_fread reads from a file.
system_fwrite writes to a file.
system_fwrite_atomic locks the given file before writing to it. This avoids interference between simultaneous writes by multiple threads.
Network I/O functions provide platform-independent, thread-safe network I/O routines. These routines work with SSL when SSL is enabled.
netbuf_grab reads from a network buffer’s socket into the network buffer.
netbuf_getc gets a character from a network buffer.
net_flush flushes buffered data.
net_read reads bytes from a specified socket into a specified buffer.
net_sendfile sends the contents of a specified file to a specified a socket.
net_write writes to the network socket.
Thread functions include functions for creating your own threads that are compatible with the server’s threads. There are also routines for critical sections and condition variables.
systhread_start creates a new thread.
systhread_sleep puts a thread to sleep for a given time.
crit_init creates a new critical section variable.
crit_enter gains ownership of a critical section.
crit_exit surrenders ownership of a critical section.
crit_terminate disposes of a critical section variable.
condvar_init creates a new condition variable.
condvar_notify awakens any threads blocked on a condition variable.
condvar_wait blocks on a condition variable.
condvar_terminate disposes of a condition variable.
prepare_nsapi_thread allows threads that are not created by the server to act like server-created threads.
Utility functions include platform-independent, thread-safe versions of many standard library functions (such as string manipulation), as well as new utilities useful for NSAPI.
daemon_atrestart (UNIX only) registers a user function to be called when the server is sent a restart signal (HUP) or at shutdown.
condvar_init gets the next line (up to a LF or CRLF) from a buffer.
util_hostname gets the local host name as a fully qualified domain name.
util_later_than compares two dates.
util_snprintf is the same as the standard library routine sprintf().
util_strftime is the same as the standard library routine strftime().
util_uri_escape converts the special characters in a string into URI-escaped format.
util_uri_unescape converts the URI-escaped characters in a string back into special characters.
You cannot use an embedded null in a string, because NSAPI functions assume that a null is the end of the string. Therefore, passing Unicode-encoded content through an NSAPI plug-in.
SAF definitions , you should define it to do certain things, depending on which stage of the request-handling process will invoke the SAF. For example, SAFs to be invoked during the Init stage must conform to different requirements than SAFs to be invoked during the Service stage.
The rq parameter is the primary mechanism for passing information throughout the request-response process. On input to a SAF, rq contains whatever values were inserted or modified by previously executed SAFs. On output, rq contains any modifications or additional information inserted by the SAF. Some SAFs depend on the existence of specific information provided at an earlier step in the process. For example, a PathCheck SAF retrieves values in rq->vars that were previously inserted by an AuthTrans SAF.
This section outlines the expected behavior of SAFs used at each stage in the request-handling process.
Init SAFs
AuthTrans SAFs
NameTrans SAFs
PathCheck SAFs
ObjectType SAFs
Input SAFs
Output SAFs
Service SAFs
AddLog SAFs
Error SAFs
Connect SAFs
DNS SAFs
Filter SAFs
Route SAFs
For more detailed information about these SAFs, see Oracle iPlanet Web Proxy Server 4.0.14 Configuration File Reference.
Purpose: Initialize at startup.
Called at server startup and restart.
rq and sn are NULL.
Initialize any shared resources such as files and global variables.
Can register callback function with daemon_atrestart() to clean up.
On error, insert error parameter into pb describing the error and return REQ_ABORTED.
If successful, return REQ_PROCEED.
Verify any authorization information. Only basic authorization is currently defined in the HTTP/1.0 specification.
Check for an Authorization header in rq->headers that contains the authorization type and uu-encoded user and password information. If a header was not sent, return REQ_NOACTION.
If a header exists, check the authenticity of user and password.
If the user name and password are authentic, create an auth-type, plus auth-user or auth-group parameter in rq->vars to be used later by PathCheck SAFs.
Return REQ_PROCEED if the user was successfully authenticated Return REQ_NOACTION otherwise.
Purpose: Convert a logical URI to a physical path.
Perform operations on the logical path (ppath in rq->vars) to convert it into a full local file system path.
Return REQ_PROCEED if ppath in rq->vars contains the full local file system path, or REQ_NOACTION if not.
To redirect the client to another site, change ppath in rq->vars to /URL. Add url to rq->vars with full URL (for example, http://home.netscape.com/). Return REQ_PROCEED.
Purpose: Check path validity and user’s access rights.
Check auth-type, auth-user, or auth-group in rq->vars.
Return REQ_PROCEED if the user and group are authorized for this area (ppath in rq->vars).
If not authorized, insert WWW-Authenticate to rq->srvhdrs with a value such as: Basic; Realm=\\"Our private area\\". Call protocol_status() to set the HTTP response status to PROTOCOL_UNAUTHORIZED. Return REQ_ABORTED.
Purpose: Determine content-type of data.
If content-type in rq->srvhdrs already exists, return REQ_NOACTION.
Determine the MIME type and create content-type in rq->srvhdrs
Return REQ_PROCEED if content-type is created, REQ_NOACTION otherwise.
Purpose: Insert filters that process incoming (client-to-server) data.
Input SAFs are executed when a plug-in or the server first attempts to read entity body data from the client.
Input SAFs are executed at most once per request.
Return REQ_PROCEED to indicate success, or REQ_NOACTION to indicate that the SAF performed no action.
Purpose: Insert filters that process outgoing (server-to-client) data.
Output SAFs are executed when a plug-in or the server first attempts to write entity body data from the client.
Output SAFs are executed at most once per request.
Return REQ_PROCEED to indicate success, or REQ_NOACTION to indicate the SAF performed no action.
Purpose: Generate and send the response to the client.
A Service SAF is only called if each of the optional parameters type, method, and query specified in the directive in obj.conf match the request.
Remove existing content-type from rq->srvhdrs. Insert correct content-type in rq->srvhdrs.
Create any other headers in rq->srvhdrs.
Call protocol_set_finfo to set the HTTP response status.
Call protocol_start_response to send the HTTP response and headers.
Generate and send data to the client using net_write .
Return REQ_PROCEED if successful, REQ_EXIT on write error, or REQ_ABORTED on other failures.
Purpose: Respond to an HTTP status error condition.
The Error SAF is only called if each of the optional parameters code and reason specified in the directive in obj.conf match the current error.
Error SAFs perform the same action as Service SAFs, but only in response to an HTTP status error condition.
Purpose: Log the transaction to a log file.
AddLog SAFs can use any data available in pb, sn, or rq to log this transaction.
Return REQ_PROCEED.
Purpose: Call the connect function you specify.
Only the first applicable Connect function is called, starting from the most restrictive object. Occasionally you might want to call multiple functions until a connection is established. The function returns REQ_NOACTION if the next function should be called. If it fails to connect, the return value is REQ_ABORT. If it connects successfully, the connected socket descriptor will be returned.
Purpose: Calls either the dns-config built-in function or a DNS function that you specify.
Purpose: Run an external command and then pipes the data through the external command before processing that data in the proxy. This process is accomplished using the pre-filter function.
Purpose: Specify information about where the proxy server should route requests.
When converting a CGI variable into a SAF using NSAPI, Since the CGI environment variables are not available to NSAPI, you’ll retrieve them from the NSAPI parameter blocks. The table below indicates how each CGI environment variable can be obtained in NSAPI.
Table 1–6 Parameter Blocks for CGI Variables
CGI getenv() |
NSAPI |
---|---|
pblock_findval("auth-type", rq->vars); |
|
pblock_findval("auth-user", rq->vars); |
|
pblock_findval("content-length", rq->headers); |
|
pblock_findval("content-type", rq->headers); |
|
"CGI/1.1" |
|
pblock_findval( "*", rq->headers); (* is lowercase; dash replaces underscore) |
|
pblock_findval("path-info", rq->vars); |
|
pblock_findval("path-translated", rq->vars); |
|
pblock_findval("query", rq->reqpb); (GET only; POST puts query string in body data) |
|
pblock_findval("ip", sn->client); |
|
session_dns(sn) ? session_dns(sn) : pblock_findval("ip", sn->client); |
|
pblock_findval( "from", rq->headers);(not usually available) |
|
pblock_findval("auth-user", rq->vars); |
|
pblock_findval("method", req->reqpb); |
|
pblock_findval("uri", rq->reqpb); |
|
char *util_hostname(); |
|
conf_getglobals()->Vport; (as a string) |
|
pblock_findval("protocol", rq->reqpb); |
|
MAGNUS_VERSION_STRING |
|
Sun ONE-specific: | |
pblock_findval("auth-cert", rq->vars) |
|
char *session_maxdns(sn);(may be null) |
|
security_active ? "ON" : "OFF"; |
|
pblock_findval("keysize", sn->client); |
|
pblock_findval("secret-keysize", sn->client); |
|
pblock_findval( query", rq->reqpb); (GET only, POST puts query string in entity-body data) |
|
http_uri2url_dynamic("","", sn, rq); |
Your code must be thread-safe under NSAPI. You should use NSAPI functions that are thread-safe. Also, you should use the NSAPI memory management and other routines for speed and platform independence.