load-config

Applicable in PathCheck-class directives.

The load-config function searches for configuration files in document directories and adds the file’s contents to the server’s existing configuration. These configuration files, also known as dynamic configuration files, specify additional access control information for the requested resource. Depending on the rules in the dynamic configuration files, the server determines whether to allow the client to access the requested resource.

Each directive that invokes load-config is associated with a base directory, which is either stated explicitly through the basedir parameter or derived from the root directory for the requested resource. The base directory determines two things:

• The topmost directory for which requests will invoke this call to the load-config function.

  For example, if the base directory is D:/sun/server1/docs/nikki/, then only requests for resources in this directory or its subdirectories and their subdirectories trigger the search for dynamic configuration files. A request for the resource D:/sun/server1/docs/somefile.html does not trigger the search in this case because the requested resource is in a parent directory of the base directory.

• The topmost directory in which the server looks for dynamic configuration files to apply to the requested resource.

  If the base directory is D:/sun/server1/docs/nikki/, the server starts its search for dynamic configuration files in this directory. It may or may not also search subdirectories (but never parent directories), depending on other factors.

When you enable dynamic configuration files through the Server Manager interface, the system writes additional objects with ppath parameters into the obj.conf file. If you manually add directives that invoke load-config to the default object rather than putting them in separate objects, the Server Manager interface might not reflect your changes.

If you manually add PathCheck directives that invoke load-config to the file obj.conf, put them in additional objects created with the <OBJECT> tag rather than putting them in the default object. Use the ppath attribute of the OBJECT tag to specify the partial path name for the resources to be affected by the access rules in the dynamic configuration file. The partial path name can be any path name that matches a pattern, which can include wildcard characters.

For example, the following <OBJECT> tag specifies that requests for resources in the directory D:/sun/proxy4/docs are subject to the access rules in the file my.nsconfig.

<Object ppath="D:/sun/server1/docs/*">PathCheck fn="load-config" 
	file="my.nsconfig" descend=1 basedir="D:/sun/server1/docs" </Object>

If the ppath resolves to a resource or directory that is higher in the directory tree or is in a different branch of the tree than the base directory, the load-config function is not invoked. The base directory specifies the highest-level directory for which requests will invoke the load-config function.

The load-config function returns REQ_PROCEED if configuration files were loaded, REQ_ABORTED on error, or REQ_NOACTION when no files are loaded.

Parameters

The following table describes parameters for the load-config function.

Examples

In this example, whenever the server receives a request for any resource containing the substring secret that resides in D:/Sun/WebServer61/server1/docs/nikki/ or a subdirectory it searches for a configuration file called checkaccess.nsconfig.

The server starts the search in the directory D:/Sun/WebServer61/server1/docs/nikki, and searches subdirectories too. It loads each instance of checkaccess.nsconfig and applies the access control rules contained in each instance to determine whether the client is allowed to access the requested resource.

<Object ppath="*secret*"> PathCheck fn="load-config" 
	file="checkaccess.nsconfig" basedir="D:/Sun/WebServer61/server1/docs/nikki" 
	descend="1" </Object>