iPlanet Request Processing

Oracle iPlanet Webserver

Request Processing

Topics Covered
• Basic Concepts
– Directives
– Templates
– Server Variables
• Request Processing Stages
– AuthTrans
– NameTrans
– PathCheck
– ObjectType
– Input
– Output
– Route
– Service
– AddLog
– Error
• Summary
• Default obj.conf file

Directives
A directive is a statement that defines a setting within the Web Server.
Directives invoke Server Application Functions(SAF) at various request processing
stages.

Format of a Directive:
<Directive> fn=“<function-name>” name1=“value1” ... nameN=“<valueN>”
where,
– <Directive> is the one of the Request Processing stage.
– <function-name> is the name of the function, which is provided by default or loaded using the
load-modules function provided in magnus.conf file.
– Name1,name2,..nameN are the parameters passed to the function.

The Order in which directives appear becomes important if the directives are
conditionally executed.

• The instructions (called directives) that identifies these options are stored in
configuration files.
• Sun Java System Web Server reads the configuration files on startup and
during client requests to map your choices with the desired server activity.

Templates
• Directives can be grouped together into Object Tags (also called as
Containers or Templates).
• Templates help in processing the Directives on conditional basis.
• The order in which Templates appear is not important.
• There exists one template with the name “default”.
– The Directives present in default object are used to process every request.
– Directives for standard Request Processing are provided after installation in
default template.
– Server will start without default template, but it will not process the requests.
Default template is mandatory for the Request Processing.
• Each new object that you add or each existing object that you modify
also modifies the behavior of the default object. You can modify and
extend the request handling process by adding or changing directives
in the obj.conf

Server Variables
• Web Server variables begin with a dollar sign character ($), followed by either
upper- or lowercase letters as the next character. Subsequent characters can
include any combination of upper- or lowercase alphanumeric characters or
underscores (_).

• Server Variables can be
– Predefined Variables
– Defined at request time through the use of set-variable SAF
– Virtual Server Specific variables defined at <virtual-server> level
– Server variables defined at the <server> level

Request Processing Stages
• Webserver has predefined stages for the entire Request Handling Process.
• Set of related functions are grouped together to perform tasks within the
Request Handling Process.
• Server may call many functions to perform the work of Request Processing.
• There might be zero or more Directives within each stage.
• Request Processing Stages are:
– AuthTrans
– NameTrans
– PathCheck
– ObjectType
– Input
– Output
– Route
– Service
– AddLog
– Error

Auth Name Path Object Add
Input Output Route Service Error
Trans Trans Check Type Log

Input &
Output
Input:
Notes • Authorization info in Request HTTP Header

Directives
Output:
• Status of User Authentication, if Header info available


Input &
Output
• AuthTrans stands for Authorization Translation.
Notes • Get User Identity as part of HTTP Header Info.
• Validates the Authenticity of User Credentials .i.e., checks if the username and
Directives password associated with the request are acceptable
• This Phase doesn’t Allow or Deny any Requests.
• When a request arrives, the AuthTrans stage checks whether the Authorization
HTTP header exists; if it does, the AuthTrans stage validates the authenticity of
the user’s credentials.
• If there are more than one AuthTrans directives defined for the object, the
Web Server processes each directive in sequential order until one succeeds in
authorizing the user. As soon as a match occurs, processing within the stage is
completed and subsequent AuthTrans directives are ignored.


Input &
Output
basic-auth: calls a custom function to verify authorization information sent by the
client.
Ex;
Notes
AuthTrans fn=basic-auth auth-type=basic userfn=hardcoded_auth
Userdefined function hardcoded_auth is being used to verify user credentials.
Directives

basic-ncsa: The basic-ncsa function verifies authorization information sent by the
client against a database
Ex;
AuthTrans fn=basic-ncsa auth-type=basic dbm=/netscape/server4/userdb/rs

get-sslid: The get-sslid function retrieves a string that is unique to the current SSL
session, and stores it as the ssl-id variable in the Session->client parameter block.

qos-handler: examines the current quality of service statistics for the virtual server,
virtual server class, and global server, logs the statistics, and enforces the QOS
parameters by returning an error


Input &
Output
Input:
Comments • Request URI

Directives
Output:
• Related OS File/Directory


Input &
Output
• NameTrans stands for Name Translation.
Notes • For the Operating System, it is files and Directories. So, the webserver must
convert the Request URI to the OS related File or Directory.
Directives • NameTrans directives translate virtual URLs to physical directories/files on the
Web server
• NameTrans directives should appear in the default object.
• If there is more than one NameTrans directive in an object, the server executes
each one in order until one succeeds.


Input & assign-name: specifies the name of an object in obj.conf that matches the current
Output request. The server then processes the directives in the named object in preference to the
ones in the default object.
Comments Ex;
NameTrans fn=assign-name name=myapp from=/zeroproductionincidents
Directives
...
<Object name=myapp>
...additional directives..
</Object>
After processing the NameTrans directive, server looks for an named object myapp in
obj.conf and start processing the objectives in myapp object.

document-root: specifies the root document directory for the server.
Ex;
NameTrans fn=document-root root=/usr/netscape/server4/docs

home-page: specifies the home page for the server.
Whenever a client requests the server's home page (/), they'll get the document specified.
Ex;
NameTrans fn="home-page" path="homepage.html"


Input & pfx2dir: replaces a directory prefix in the requested URL with a real directory name. It
Output also optionally allows you to specify the name of an object that matches the current
request
Comments Ex;
NameTrans fn=“pfx2dir” from=“/images/banner” dir=“/homepage/defaultimages”
Directives
name=“myimages”
servername/images/banner/logo.gif will be translated to the file
/homepage/defaultimages/logo.gif and server also starts processing the directives in
the object named myimages.

redirect: lets you change URLs and send the updated URL to the client
Ex;
NameTrans fn=“redirect” from=“/” url-prefix=“http://newserver”
Any request for http://server-name/resource is translated to a request for
http://newserver/resource

unix-home: translates user names (typically of the form ~username) into the user's
home directory on the server's Unix machine.
Ex;
NameTrans fn=“unix-home” from=“/~” subdir=“public_html”
servername/~ will be translated to the user subdirectory “public_html” within the user's
home directory.


Input &
Output
Input:
Comments • OS File/Directory path

Directives
Output:
• Directory / File path removing malicious data
• User Authorization
• Index file, if the request URI is a Directory.
• Welcome-file-list, if the request URI is a web Application.


Input &
Output
PathCheck Directives perform the following tasks on the resulting path:
Notes
• Cleanup any malicious directories (ex;. ,.,.. etc.) and dangerous
Directives elements.
• Determine whether the requested resource is a web application or a
directory in the file system and verification of its existence.
• Access Control Processing to determine whether the user is allowed to
access the requested resource.


Input &
check-acl:
Output • specifies an Access Control List (ACL) to use to check whether the client is allowed to access the
requested resource.
Notes • An access control list contains information about who is or is not allowed to access a resource,
and under what conditions access is allowed.
• You can also specify under what conditions (i.e., client IP address, day of week, or authentication
Directives method) that the access is granted.
• Regardless of the order of PathCheck directives in the object, check-acl functions are executed
first. They cause user authentication to be performed, if required by the specified ACL, and will
also update the access control state. Ex;
PathCheck fn="check-acl" acl="default"
Default acl is applied on the requests, where path for default can be specified in the server.xml
file.

• If an ACL specifies access based on a particular user or group and the user is not known (i.e., has
not authenticated), Web Server responds to the client with a status of 401 (Unauthorized) and
completes the processing of the request.
• This status informs the browser that it needs to open a dialog box to prompt the user for a
username and password.
• The browser sends the credentials, along with the original URL, to the Web Server where they
will then be validated in the AuthTrans stage.
• If access is denied, the server switches to executing directives in the Error stage, where a status
code of 403 (Forbidden) is returned to the client.


Input &
deny-existence: sends a "not found" message when a client tries to access a specified
Output path. The server sends "not found" instead of "forbidden," so the user cannot tell
whether the path exists or not.
Notes Ex;
PathCheck fn=deny-existence path=/mysite/docs/private

Directives
find-index: investigates whether the requested path is a directory.
If it is, the function searches for an index file in the directory, and then changes the path
to point to the index file.
If no index file is found, the server generates a directory listing (if directory listing is
turned on).
Ex;
PathCheck fn=find-index index-names=index.html,home.html

find-links: Searches the current path for symbolic or hard links to other directories or
file systems. If any are found, an error is returned.
Disable -> h is hard links.
s is soft links
o allows symbolic links from user home directories only if the user owns the
target of the link.
Ex;
PathCheck fn=find-links disable=sh dir=/foreign-dir


Input &
find-path-info: finds any extra path information after the file name in the URL and
Output stores it for use in the CGI environment variable PATH_INFO.
Ex;
Notes PathCheck fn=find-pathinfo

Directives
find-index-j2ee: Implements welcome file processing for Java web applications.
Welcome files are specified in web.xml file. The list of welcome files in web.xml is used
by the Java web container when the request corresponds to a directory within a Java
web application.

The find-index-j2ee SAF appends each of the partial URIs that specify a welcome file (in
the order in which they are specified in web.xml) to the request URI and sends the
request to the first resource that matches this concatenated URI.

This SAF acts upon only those URIs that map to directories within the Java web
application and even then takes no action when no welcome files are specified in
web.xml or when none of the welcome files match a resource.


Input &
load-config: searches for configuration files in document directories and adds the
Output file's contents to the server's existing configuration. These configuration files specify
additional access control information for the requested resource. Depending on the
Notes rules in the dynamic configuration files, the server might or might not allow the client to
access the requested resource.
Ex;
Directives
<Object ppath="*secret*">
PathCheck fn="load-config" file="checkaccess.nsconfig" basedir=“/docs/wwwi"
descend="1"
</Object>

Whenever the server receives a request for any resource containing the substring
‘secret’ that resides in /docs/www/ or a subdirectory thereof, Server searches for
checkaccess.nsconfig file in the ‘/docs/www/’ and its subdirectories.

It loads each instance of checkaccess.nsconfig that it finds, applying the access control
rules contained therein to determine whether the client is allowed to access the
requested resource or not.


Input &
get-client-cert: gets the authenticated client certificate from the SSL3 session. It can
Output apply to all HTTP methods, or only to those that match a specified pattern. It only works
when SSL is enabled on the server.
Notes Ex;
PathCheck fn="get-client-cert" dorequest="1"

Directives
require-auth: allows access to resources only if the user or group is authorized.
Ex;
PathCheck path=“/www/admin” fn=require-auth auth-type=basic realm=“admin"
auth-group=admin auth-user=(johnM|RamG|RahimA)
Above mentioned users are allowed to access the /www/admin folder and files.

set-virtual-index: specifies a virtual index for a directory, which determines the URL
forwarding.
Ex;
PathCheck fn=set-virtual-index virtual-index=MyLWApp

ssl-check: function is designed to be used together with a Client tag to limit access of
certain directories to non-exportable browsers.

ssl-logout: invalidates the current SSL session in the server's SSL session cache.


Input &
Output
Input:
Comments • OS File/Directory path

Directives
Output:
• Server determines the Multipurpose Internet Mail Extension (MIME)
type attributes of the resource requested by the client.


• ObjectType directives determine the MIME type of the file to send to the client in
Input &
Output response to a request. These attributes may be one or more of the following:
type - The type of content being processed
Comments
encoding - How the content is encoded to the client
language - The language to use to read the content
• MIME attributes currently sent are type, encoding, and language.
Directives
• MIME type sent to the client as the value of the content-type header. When the server
sends the response to the client, the type, enc, and lang values are transmitted in the
headers of the response. This tells the client how to process the data.
• On the server side, the type attribute can be used to tell the Web Server which Service
directive to execute to generate the response to the client
• If there is more than one ObjectType directive, the server continues to process all
directives in the order in which they appear even if a match has already occurred.
After a directive sets a MIME attribute (type, enc, lang), further attempts to set the
same attribute are ignored. This continuation of processing allows Web Server the
flexibility to set one attribute in one directive (such as type) and a different attribute in
a different directive (such as lang).


Input & force-type:
Output
• assigns a type to requests that do not already have a MIME type. This is used to
specify a default object type.
Comments
• The directive that calls this function comes last in the list of ObjectType directives so
that all other ObjectType directives have a chance to set the MIME type first.
Directives • If there is more than one ObjectType directive in an object, all the directives are
applied in the order they appear. If a directive sets an attribute and later directives
try to set that attribute to something else, the first setting is used and the
subsequent ones ignored.
Ex;
ObjectType fn=force-type type=text/plain
ObjectType fn=force-type lang=en_US

set-default-type: allows you to define a default charset, content-encoding, and
content-language for the response being sent back to the client.
Ex;
ObjectType fn="set-default-type" charset="iso_8859-1"


Input &
Output shtml-hacktype: function changes the content-type of any .htm or .html file to
magnus-internal/parsed-html
Comments Ex;
ObjectType fn=shtml-hacktype exec-hack=true
Directives
type-by-exp: function matches the current path with a wildcard expression. If the two
match, the type parameter information is applied to the file. This is the same as type-by-
extension, except you use wildcard patterns for the files or directories specified in the
URLs.
Ex;
ObjectType fn=type-by-exp exp=*.test type=application/html

type-by-extension: function instructs the server to look in a table of MIME type
mappings to find the MIME type of the requested resource according to the extension
of the requested resource. The MIME type is added to the content-type header sent
back to the client.
Ex;
ObjectType fn=type-by-extension


Input &
Output
Input:
Comments • HTTP Request

Directives
Output:
• Filters execute on the Entity body, based on the configuration & Type
of filters.


Input &
Output
• Before the response is generated, the server or plugin first attempts to
Comments read entity body data from the client and the Input directive is executed.
• The Input directive selects filters that process incoming request data.
Directives • It enables you to invoke the insert-filter SAF to install filters that process
incoming data.


Input &
Output
Input fn=”insert-filter” filter=”http-decompression”
Comments
The above directive instructs the insert-filter function to add a filter named
Directives httpdecompression to the filter stack. This filter would effectively decompress
incoming HTTP request data before passing it to the next stage in the request
processing.


Input &
Output
Input:
Comments • Response data

Directives
Output:
• Filters execute on the Response data, based on the configuration &
Type of filters.


Input &
Output
• The Output directive selects filters that process outgoing response data
Comments generated by the Service step.
• The Output directive lets you invoke the insert-filter SAF to install filters
Directives that process outgoing data.
• All Output directives are executed when the server (or a plug-in) first
attempts to write entity body data to the client.


Input &
Output
After the Service stage has completed processing and a response has been
Comments generated, you may want to compress the response data before sending it
back to the client. This can be performed in the following Output directive:
Directives
Output fn=”insert-filter” filter=”http-compression”

This directive instructs the insert-filter function to add a filter named http-
compression to the filter stack, which would compress outgoing HTTP
response data.


Input &
Output
Input:
Comments • NONE

Directives
Output:
• HTTP Request sent to another server


Input &
Output
• If a Service directive requires that the HTTP request be sent to another
Comments server, the server executes Route directives to determine how the request
should be routed.
Directives
• Routing a request can involve selecting the server that will ultimately
service the request and selecting a proxy through which the request may
be sent.


Input &
Output
set-origin-server: specifies the origin server that will service the request.
Comments
Ex;
Route fn=”set-origin-server”
Directives
server=”http://myapp.zeroproductionincidents.com:8080”
server=”http://myapp.zeroproductionincidents.com:8090”


Input &
Output
Input:
Comments • HTTP Request

Directives
Output:
• Generate Response


Input & • Generate the response to send to the client.
Output
• The server looks at each Service directive to find the first one that matches
Comments
the type, method, and query string. If a Service directive does not specify
type, method, or query string, then the unspecified attribute matches
anything.
Directives
• If there is more than one Service directive, the server applies the first one
that matches the conditions of the request and ignores all remaining
Service directives.
• After the server has determined what type of resource the client is
requesting in the ObjectType stage, it then needs to call the appropriate
SAF to generate a response to the client. This determination is made and
the action is performed in the Service stage.


Input & add-footer: This function appends a footer to an HTML file that is sent to the client.
Output
The footer is specified either as a filename or a URI -- thus the footer can be dynamically
generated. To specify static text as a footer, use the append-trailer function.
Comments
Service type=text/html method=GET fn=add-footer file="footers/footer1.html"

Directives add-header: This function prepends a header to an HTML file that is sent to the client.
The header is specified either as a filename or a URI -- thus the header can be
dynamically generated.
Ex;
Service type=text/html method=GET fn=add-header file="headers/header1.html"

append-trailer: The append-trailer function sends an HTML file and appends text to
the end. It only appends text to HTML files. This is typically used for author information
and copyright text. The date the file was last modified can be inserted
Ex;
# Add a trailer with the date in the format: MM/DD/YY
Service type=text/html method=GET fn=append-trailer timefmt="%D" trailer="<HR>File
last updated on: :LASTMOD:"


Input & Image-map: The imagemap function responds to requests for imagemaps. Imagemaps
Output are images which are divided into multiple areas that each have an associated URL. The
information about which URL is associated with which area is stored in a mapping file.
Comments Ex;
Service type=magnus-internal/imagemap method=(GET|HEAD) fn=imagemap
Directives

Index-common: generates a fancy (or common) list of files in the requested directory.
The list is sorted alphabetically.
Ex;
Service fn=index-common type=magnus-internal/directory method=(GET|HEAD)
header=hdr readme=rdme.txt

Index-simple: generates a simple index of the files in the requested directory. It scans
a directory and returns an HTML page to the browser displaying a bulleted list of the
files and directories in the directory.
Ex;
Service type=magnus-internal/directory fn=index-simple


Input &
key-toosmall: The key-toosmall function returns a message to the client specifying
Output that the secret key size for SSL communications is too small. This function is designed to
be used together with a Client tag to limit access of certain directories to non-
Comments exportable browsers.
<Object ppath=/mydocs/secret/*>
Service fn=key-toosmall
Directives
</Object>

list-dir : The list-dir function returns a sequence of text lines to the client in response to
a request whose method is INDEX.
Service fn=list-dir method="INDEX"

make-dir: creates a directory when the client sends a request whose method is
MKDIR. The function can fail if the server can't write to that directory.
Service fn="make-dir" method="MKDIR"

query-handler: runs a CGI program instead of referencing the path requested.
Service query=* fn=query-handler path=/http/cgi/do-grep


Input &
remove-dir : removes a directory when the client sends an request whose method is
Output RMDIR. The directory must be empty (have no files in it). The function will fail if the
directory is not empty or if the server doesn't have the privileges to remove the
Comments directory.
Service fn="remove-dir" method="RMDIR"

Directives
remove-file: deletes a file when the client sends a request whose method is DELETE. It
deletes the file indicated by the URL if the user is authorized and the server has the
needed file system privileges.
Service fn="remove-file" method="DELETE"

rename-file: renames a file when the client sends a request with a New-URL header
whose method is MOVE. It renames the file indicated by the URL to New-URL within the
same directory if the user is authorized and the server has the needed file system
privileges.
Service fn="rename-file" method="MOVE"


Input &
send-cgi: sets up the CGI environment variables, runs a file as a CGI program in a new
Output process, and sends the results to the client
<Object name="default">
Comments NameTrans fn="pfx2dir" from="/cgi-bin" dir="/home/foo.com/public_html/cgi-
bin" name="cgi"
</Object>
Directives
<Object name="cgi">
ObjectType fn="force-type" type="magnus-internal/cgi"
Service fn="send-cgi" user="$user" group="$group" dir="$dir" chroot="$chroot"
</Object>

send-file: sends the contents of the requested file to the client. It provides the content-
type, content-length, and last-modified headers.
Service type="*~magnus-internal/*" method="(GET|HEAD)" fn="send-file"
<Object name=default>
...
NameTrans fn="pfx2dir" from="/myurl" dir="/export/mydir", name="myname"
...
Service method=(GET|HEAD|POST) type=*~magnus-internal/* fn=send-file
</Object>
<Object name="myname">
Service method=(GET|HEAD) type=*~magnus-internal/* fn=send-file nocache=""
</Object>


send-range: When the client requests a portion of a document, by specifying HTTP
Input &
Output
byte ranges, the send-range function returns that portion.
Service fn=send-range
Comments
send-shellcgi: For Windows NT only. The send-shellcgi function runs a file as a shell
CGI program and sends the results to the client.
Directives Service fn=send-shellcgi
Service type=magnus-internal/cgi fn=send-shellcgi

send-wincgi : For Windows NT only. The send-wincgi function runs a file as a Windows
CGI program and sends the results to the client.
Service fn=send-wincgi
Service type=magnus-internal/cgi fn=send-wincgi

service-dump: The service-dump function creates a performance report based on
collected performance bucket data. To read the report, use :
http://server_id:port/.perf
<Object name=default>
NameTrans fn="assign-name" from="/.perf" name="perf"
</Object>
<Object name=perf>
Service fn="service-dump"
</Object>


shtml_send: parses an HTML document, scanning for embedded commands. These
Input &
Output
commands may provide information from the server, include the contents of other files,
or execute a CGI program. The shtml_send function is only available when the Shtml
plugin (libShtml.so on Unix libShtml.dll on Windows NT) is loaded.
Comments
Service type=magnus-internal/shtml_send method=(GET|HEAD) fn=shtml_send

Directives stats-xml: creates a performance report in XML format. If performance buckets have
been defined, this performance report includes them.
you do need to initialize this function using the stats-init function in magnus.conf, then
use a NameTrans function to direct requests to the stats-xml function.
The report is generated here:
http://server_id:port/stats-xml/iwsstats.xml
In magnus.conf
Init fn="stats-init" update-interval="5" virtual-servers="2000" profiling="yes"
In obj.conf
...
NameTrans fn="assign-name" from="/stats-xml/*" name="stats-xml"
...
</Object>
<Object name="stats-xml">
Service fn="stats-xml"
</Object>


upload-file: The upload-file function uploads and saves a new file when the client
Input &
Output
sends a request whose method is PUT if the user is authorized and the server has the
needed file system privileges.
Comments
Service fn=upload-file

Directives


Input &
Output
Input:
Comments • NONE

Directives
Output:
• Add entries to log files


Input &
Output
• After the Web Server has generated a response and has sent it to the client
Comments in the Service stage, it then executes any AddLog directives it finds to add
entries to the appropriate log file(s).
Directives
• You can have multiple AddLog directives, thus enabling you to add entries
to multiple log files.

• AddLog directives are processed after the response has been sent to the
client. This minimizes the amount of time it takes to process a request from
the client’s perspective because it does not need to wait for Web Server to
write information to log files.


Input &
Output
An example of the default AddLog directive immediately after installation is as
Comments follows:
AddLog fn=”flex-log”
Directives
This directive uses the flex-log SAF to log information about the current
request.
The data is sent to the file specified in the <access-log> element defined in the
server.xml as follows:
<access-log>
<file>../logs/access</file>
</access-log>


Input &
Output
Input:
Comments • Error during Request Processing

Directives
Output:
• Sends the relevant HTTP Status Code and the Error Page to the client


Input & • If an error occurs during the request handling process then the currently executing
Output
SAF sets the HTTP response status code and then indicates that an error has
occurred by returning the appropriate return code.
Comments
• When this occurs, the server stops processing the request and begins searching for
an Error directive that has a reason attribute that matches either of the following
Directives two conditions:
• HTTP response status code (for example, 403)
• Its associated reason phrase (for example, Unauthorized)

• If the Web Server finds a match, then it returns the document specified in the path
variable. If the Web Server does not find a matching Error directive, it simply returns
the response status code to the client.


Input & send-error: Define an Error directive to return a customized error message rather than
Output
a generic error code response:
Error fn=”send-error” reason=”Unauthorized” path=”/sun/MyDocs/errors/unauthorized.html”
Comments

error-j2ee: handles errors that occur during execution of web applications deployed
Directives to the Web Server individually or as part of full Java EE applications.

qos-error: returns an error page stating the quality of service that caused the
error, and the value of the QOS statistic.
Error fn="qos-error" code="503"

Request Processing Stages - Summary
AuthTrans
Objective Task Directive
calls a custom function to verify user name and password basic-auth
Verify User
Authentication verifies user name and password against an NCSA-style or system basic-ncsa
DBM database
Retrieves SSL retrieves a string that is unique to the current SSL session and stores get-sslid
Session it as the ssl-id variable
Quality of Services handles the current quality of service statistics qos-handler

NameTrans
Override default tells the server to process directives in a named object assign-name
Directives
translates a URL into a file system path document-root

Translates URL translates server's root home page (/) to a specific file home-page
translates URL beginning with given prefix to file system directory pfx2dir
translates user names into user's home directory on Unix machine unix-home
Redirection Redirects to a different url redirect
removes embedded semicolon-delimited parameters from path strip-params

PathCheck
Remove Malicious Directories & Clean up the URI uri-clean
Dangerous elements
Directory Listing Locates a default file when directory is requested find-index

Virtual Index specifies a virtual index for a directory Set-virtual-index

Send resource not found to client deny-existence

Denies access to directories with certain file system links find-links
Authorization
specify additional access control information for the load-config
requested resource
Check access control list check-acl

denies access to unauthorized users or groups require-auth

denies access to requests with unsafe path names by Unix-uri-clean
indicating not found
Assign CGI environment variable locates extra path info beyond the file name for the find-pathinfo
PATH_INFO CGI environment variable
Checks the Secret Keysize ssl-check

SSL invalidates the current SSL session in the server's SSL session Ssl-logout
cache
gets the authenticated client certificate get-client-cert

ObjectType
based on Request Type Force-type
Sets Response
Sets default type Set-default-type
MIME Attribute
(Content-Type) Special parsing for html & htm files Shmtl-hacktype
based on Requested path Type-by-exp
based on files extension & MIME Types Type-by-extension

Input
Insert Filter Insert Filter Insert-filter

Output
Insert Filter Insert Filter Insert-filter

Route
Set the Server Set Origin Server set-origin-server

Service
Appends Footer add-footer

Manipulate Response Prepends Header add-header

Appends Text to the end of HTML file append-trailer

Directory Listing generates a fancy list of the files and directories Index-common

generates a simple list of files and directories Index-simple

Lists contents of a directory List-dir

SSL indicates to the client that the provided certificate key size is Key-toosmall
too small to accept
Creates a directory Make-dir

Directory & File Manipulation Deletes an empty directory Remove-dir

Deletes a file Remove-file

Renames a file Rename-file

Uploads and Saves new file Upload-file

Service
Service Task Directive
sets up environment variables, launches a CGI program, and send-cgi
sends the response to the client
sends a local file to the client. send-file

sends a range of bytes of a file to the client. send-range
Send Response
sets up environment variables, launches a shell CGI program, send-shellcgi
and sends the response to the client.
sets up environment variables, launches a WinCGI program, send-wincgi
and sends the response to the client.
handles server-side image maps imagemap

runs a CGI program instead of referencing the path query-handler
requested
parses an HTML file for server-parsed html commands shtml-send

creates a performance report based on collected Service-dump
Performance Reports performance bucket data
creates a performance report in XML format. Stats-xml

AddLog
Add Log Add Log entries flex-log

Error
Send the Error response to the client Send-error

Send Error Handles errors that occur during execution of web applications error-j2ee

Returns an error page stating the quality of service that caused the qos-error
Error

Default obj.conf file
AuthTrans fn="match-browser" browser="*MSIE*" ssl-unclean-shutdown="true"
NameTrans fn="ntrans-j2ee" name="j2ee"
NameTrans fn="pfx2dir" from="/mc-icons" dir="F:/Wissen-Public/Lab-Env/Servers/iPlanet/lib/icons" name="es-internal"
PathCheck fn="uri-clean"
PathCheck fn="check-acl" acl="default" AuthTrans
PathCheck fn="find-pathinfo"
PathCheck fn="find-index-j2ee"
PathCheck fn="find-index" index-names="index.html,home.html,index.jsp" NameTrans
ObjectType fn="type-j2ee"
ObjectType fn="type-by-extension"
ObjectType fn="force-type" type="text/plain" PathCheck
Service method="(GET|HEAD)" type="magnus-internal/directory" fn="index-common"
Service method="(GET|HEAD|POST)" type="*~magnus-internal/*" fn="send-file"
Service method="TRACE" fn="service-trace"
ObjectType
Error fn="error-j2ee"
AddLog fn="flex-log"
</Object>
Input
<Object name="j2ee">
Service fn="service-j2ee" method="*" Output
</Object>
<Object name="es-internal">
PathCheck fn="check-acl" acl="es-internal" Route
</Object>
<Object name="cgi">
ObjectType fn="force-type" type="magnus-internal/cgi" Service
Service fn="send-cgi"
</Object>
<Object name="send-precompressed"> AddLog
PathCheck fn="find-compressed"
</Object>
<Object name="compress-on-demand"> Error
Output fn="insert-filter" filter="http-compression"
</Object>

iPlanet Request Processing

Recommandé

Recommandé

Contenu connexe

Similaire à iPlanet Request Processing

Similaire à iPlanet Request Processing (20)

Dernier

Dernier (20)

iPlanet Request Processing

Notes de l'éditeur