This section summarizes the various APIs and programming technologies supported by Web Server, and describes how to get more information about them. The main categories of extensions and modifications you can make to Web Server are listed below:
Web Server 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.
For more information about defining and using server-parsed tags, see Chapter 2, Server-parsed HTML Tags.
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, and Perl, and as shell scripts. CGI programs are invoked through URL invocation.
Web Server complies with the version 1.1 CGI specification.
For more information about using CGI with Web Server, see Chapter 2, Server-parsed HTML Tags
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. Servlets are accessed through URL invocation.
You create servlets using the Java Servlets API. Web Server includes all of the files necessary for developing and running Java servlets.
For information about using the Java Servlet API, see the documentation from Sun at: http://java.sun.com/products/servlet/index.jsp
A JSP page is a page that can be viewed in a web browser, much like an HTML page. 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 about creating web applications that use servlets and JSPs on Web Server, see the Sun Java System Web Server 7.0 Developer’s Guide to Java Web Applications.
For more information about using JavaServer Pages, see the documentation from Sun at: http://java.sun.com/products/jsp/index.jsp
Using NSAPI, you can write plug-ins to extend the functionality of Web Server. An NSAPI plug-in defines one or more Server Application Functions (SAFs). You can develop SAFs for implementing custom authorization, custom logging, and for other ways of modifying how Sun Java System Web Server handles requests. For more information, see the Sun Java System Web Server 7.0 NSAPI Developer’s Guide.
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 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 7.0</font></H4>. The append-trailer function simply returns the requested resource to the client, in this case an HTML file, and appends the given trailer to it.
Service method=GET type="text/html" fn=append-trailer trailer= "<H4><font color=green>Served by 7.0</font></H4>"
Web Server has a set of predefined SAFs. It also has a library of NSAPI functions for developing your own SAFs to modify the way the server handles requests. For more information about predefined SAFs, see the Sun Java System Web Server 7.0 Administrator’s Configuration File Reference . For more information about custom SAFs, see the Sun Java System Web Server 7.0 NSAPI Developer’s Guide.
The file obj.conf is essential for the operation of the server. If it does not exist, the server cannot work, because it has nowhere to look for instructions on how to handle requests.
To load new NSAPI plug-ins 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.
See the Sun Java System Web Server 7.0 NSAPI Developer’s Guide for more information about the following topics:
Directives in obj.conf and how they determine how the server handles requests
NSAPI functions available for writing custom SAFs
Writing custom SAFs
For more information about the predefined SAFs that are included with Web Server, see the Sun Java System Web Server 7.0 Administrator’s Configuration File Reference.
Access control lists (ACLs) determines the access privileges to the resources on the server. Each ACL contains a list of access control entries. The following access control entry, for example, specifies 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 ACL:
From the Common Task screen select the configuration from the drop-down list and click Edit Configurations tab.
Click Access Control tab in the configuration screen.
Click Access Control Lists (ACL) tab in the Authentication Databases screen.
Click New to create an ACL.
With Web Server you can configure and reference multiple ACL files. For more information about configuring ACL files for virtual servers, see the Sun Java System Web Server 7.0 Administrator’s Guide.
With the Access Control API you can manipulate 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 e-mail address or on the URL that referred them to the resource:
allow (read) referer="*www.acme.com*"
You can also authenticate the client based on your own authentication methods and databases.
You must Define your own Loadable Authentication Service (LAS), which is an NSAPI plug-in. For the server to use your attributes for authentication. 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.
The Certificate-Mapping API consists of data structures and functions used to manage certificate mapping.
When a user authenticates to the Web Server by sending a client certificate, 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 certdb.conf. This file specifies the following:
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 certmap.conf, see the Sun Java System Web Server 7.0 Administrator’s Configuration File Reference.
You can also modify this process programmatically. Web Server includes 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 must have a copy of the Directory SDK. You can download a copy of this SDK from the following location: http://developers.sun.com/index.html.