Module core

The AcceptPathInfo directive controls whether requests that contain trailing pathname information, that follows an actual filename or nonexistent file in an existing directory, are accepted or rejected. The trailing pathname information can be made available to scripts in the PATH_INFO environment variable.

For example, assume the location /test/ points to a directory that contains only the single file here.html. Requests for /test/here.html/more and /test/nothere.html/more both collect /more as PATH_INFO.

Parameter: On | Off | Default

• When set to On, a request will be accepted if a leading path component maps to a file that exists. The above example /test/here.html/more will be accepted if /test/here.html maps to a valid file.
• When set to Off, a request will only be accepted if it maps to a literal path that exists. Therefore a request with trailing pathname information after the true filename such as /test/here.html/more in the above example will return a 404 NOT FOUND error.
• When set to Default, the treatment of requests with trailing pathname information is determined by the handler responsible for the request. The core handler for normal files defaults to rejecting PATH_INFO. Handlers that serve scripts, such as cgi-script and isapi-isa, generally accept PATH_INFO by default.

The primary purpose of the AcceptPathInfo directive is to allow you to override the handler's choice of accepting or rejecting PATH_INFO. This override is required, for example, when you use a filter (such as INCLUDES) to generate content based on PATH_INFO. The core handler would usually reject the request. You can use the following configuration to enable such a script:

<Files "mypaths.shtml">
Options +Includes
SetOutputFilter INCLUDES
AcceptPathInfo on
</Files>

The AcceptThreads directive specifies the maximum number of accept threads per server child process. If a value is not specified, the server will use a limit of four accept threads. The accept threads are used to accept new connections from the client. This number may need to be changed to reflect the number of concurrent connections which are being accepted. If a large number of connections to the Web server start at approximately the same time, the number of accept threads may need to be adjusted to a higher value.

Parameter: number

• The number value specifies the maximum number of accept threads per server child process. Valid values include 1 through 20.

When returning a document to the client, the server looks for the first access control file in the list of names in every document directory path. This only happens if the access control files are enabled for the directory. For example:

AccessFileName .acl

Before returning the document /QIBM/UserData/web/index.html, the server will read /.acl, /QIBM/.acl, /QIBM/UserData/.acl and /QIBM/UserData/web/.acl for directives, unless they have been disabled with the following:

<Directory/> 
   AllowOverride None 
</Directory> 

Parameter: filename

• Filename is any valid filename on the IBM i server.

If multiple occurrences of this directive are configured in a container, only the last occurrence is processed. All other occurrences are ignored.

See also AllowOverride.

The AddDefaultCharset directive specifies the character set name that will be added to any response that does not have a parameter on the content type in the HTTP headers. This will override any character set specified, in the document body, by a META tag.

Parameter: on | off | charset

• AddDefaultCharset on enables HTTP Server's internal default charset of iso-8859-1 as required by the directive.
• AddDefaultCharset off disables this functionality.
• Alternate charset can be specified, for example, AddDefaultCharset on utf-8.

The AddOutputFilterByType directive matches the MIME content-type of files to a filter which will process responses from the server before they are sent to the client. All files of the given content-type will be processed through the filter filtername. This is in addition to all defined filters, including those defined in the SetOutputFilter directive.

Parameter One: filtername

• The name of a filter which will process responses from the server before they are sent to the client.

Parameter Two: content-type

• Any valid MIME-type.

To process the the content by more than one filter, the names have to be separated by semicolons. It is also possible to use one AddOutputFilterByType directive for each of these filters. The configuration below causes all script output labeled as text/html to be processed first by the INCLUDES filter and then by the DEFLATE filter.

<Location /cgi-bin/>
Options Includes
AddOutputFilterByType INCLUDES;DEFLATE text/html
</Location>

The AllowEncodedSlashes directive allows URLs which contain encoded path separators (%2F for / and additionally %5C for \ on according systems) to be used. Normally, such URLs are refused with a 404 (Not found) error. Turning AllowEncodedSlashes on is useful when used in conjunction with PATH_INFO environment variable.

Parameter: on | off

• The on parameter value specifies that URLs with encoded path separators can be used.
• The off parameter value specifies that URLs with encoded path separators will result in a 404 (Not found) error.

When the server finds an .htaccess file (as specified by AccessFileName) it needs to know which directives declared in that file can override earlier access information.

Parameter: override

• Override can be set to one or more of the following

The AuthName directive sets the name of the authorization realm for a directory. This realm is given to the client during basic authentication to inform the user about which username and password to send. To work properly this directive must be accompanied by AuthType Basic, and directives such as PasswdFile.

Parameter: auth-domain

• The auth-domain parameter values specifies a single argument; if the realm name contains spaces, it must be enclosed in double quotation marks.

The AuthType directive selects the type of user authentication for a directory. For Basic authentication to work properly this directive must be accompanied by AuthName. If Kerberos is specified, the Require directive must be specified and the PasswdFile directive should be included and set to %%KERBEROS%%. The AuthName, LDAPConfigFile, and LDAPRequire directives may be configured in the same container, but will be ignored.

Parameter: type

• The type parameter value specifies the type of user authentication for a directory. Valid values include:

  Basic

  Configuring "AuthType Basic" specifies that the server protects resources based on a user ID and password. The user will be prompted for a user ID and password the first time a request is made for a resource protected by this directive. This directive may be used on either a secure or a non-secure HTTP session. On a non-secure HTTP session, the user ID and password are encoded, but not encrypted.

  Note: Note: In order to use the directive "SSLAuthType CertOrBasic", the AuthType directive must be specified with a value of type Basic.

  SSL

  Configuring "AuthType SSL" specifies that the server will protect resources based on a SSL client certificate that is associated with a user ID. See the SSLAuthType directive for more information.

  Note: In order to use the directive "SSLAuthType Cert", the AuthType directive must be specified with a value of type SSL.

  Kerberos

  Configuring "AuthType Kerberos" specifies that the server will accept a server ticket from a Kerberos-enabled client to authenticate a user.

  KerberosOrBasic

  Configuring "AuthType KerberosOrBasic" specifies that the server will give a basic authentication prompt to those browsers who are either not in a kerberos enabled domain, not using Microsoft Internet Explorer, or if kerberos authentication fails for a Microsoft Internet Explorer browser in a kerberos realm. If the browser is Microsoft Internet Explorer configured for kerberos, and in a kerberos domain with the correct kerberos principal and keytab entries, there will be no prompt (uses kerberos HTTP negotiation). To work correctly the intersection of directives for "Kerberos" and "Basic" authority must be used. Kerberos specific directives will not work, because basic authentication can not use kerberos validation. These directives are required when using KerberosOrBasic:

  • AuthName
  • PasswdFile %%SYSTEM%%
  • Require: The parameter valid-user, user or group may be specified. For example: Require user kerbuser@DOMAIN.COM as400userid

  Notes®:

  • The group file must include both the kerberos principal and the as400userid. For example Groupfile: productionusers: johndoe@WIN2003.DOMAIN.COM, jdoe
  • If you do not use the valid-user you must include both the kerberos client principal and the as400 userid to which it maps.

If you want to have SSL certificate checking, it is recommended that AuthType be set to type SSL.

There will be times when the server is asked to provide a document whose type cannot be determined by its MIME types mappings. The server must inform the client of the document content-type, so in the event of an unknown type it uses the DefaultType.

Parameter: MIME-type

• The MIME-type value specifies the document content-type.

For example:

DefaultType image/gif

This would be appropriate for a directory which contained many gif images with filenames missing the .gif extension. This would also be useful for documents in the QSYS.LIB file system, so you do not have to set the member type field.

<Directory> and </Directory> are used to enclose a group of directives that only apply to the named directory and subdirectories of that directory. Any directive that is allowed in a directory context may be used.

Parameter: directory

• A directory is either the full path to a directory or a wildcard string. Refer to <DirectoryMatch> for details regarding wildcard strings. Full path directory example:

  <Directory /usr/local/httpd/htdocs> 
  Options Indexes 
  FollowSymLinks 
  </Directory> 

If multiple (non-regular expression) directory sections match the directory (or its parents) containing a document, then the directives are applied in the order of shortest match first, interspersed with the directives from the .htaccess files. See AccessFileNamefor more information. For example:

<Directory /> 
   AllowOverride None 
</Directory> 

<Directory /home/*> 
   AllowOverride FileInfo 
</Directory>

For access to the document /home/web/dir/doc.html the steps are:

• Apply directive AllowOverride None (disabling .htaccess files).
• Apply directive AllowOverride FileInfo (for directory /home/web).
• Apply any FileInfo directives in /home/web/.htaccess.

Regular expressions are not considered until all of the normal sections have been applied. Then all of the regular expressions are tested in the order they appeared in the configuration file. For example:

<Directory ~ abc$> 
... directives here .. 
</Directory>

Suppose that the filename being accessed is /home/ABC/public_html/ABC/index.html. The server considers each of /, /home, /home/ABC, /home/ABC/public_html and /home/ABC/public_html/ABC in that order. The regular expression would not be considered until all normal <Directory> and .htaccess files have been applied. Then the regular expression will match on /home/ABC/public_html/ABC and be applied.

<DirectoryMatch> and </DirectoryMatch> are used to enclose a group of directives that only apply to the named directory and subdirectories of that directory. It is the same as <Directory>; however, it takes an argument as a regular expression. For example:

<DirectoryMatch "^/www/.*/[0-9]{3}">

This would match directories in /www/ that consisted of three numbers.

Parameter: regex

• Regex is a UNIX-style regular expression that is matched against the URL. Subexpressions are grouped within parentheses. Then, parenthetically enclosed regular expressions will be substituted in a subsequent $n statement.

See also <Directory>.

The DocumentRoot directive sets the directory from which HTTP Server will serve files. If the URL is not matched by a directive like Alias, the server appends the path from the requested URL to the document root and makes the path to the document.

Parameter: directory-path

• Directory-path is any valid directory path on the IBM i server.

For example:

DocumentRoot /usr/web 

An access to http://www.my.host.com/index.html refers to /usr/web/index.html.

If the DocumentRoot directive is used in the server context and the directory does not exist, the server will not start. If the DocumentRoot directive is used in a virtual host context and the directory does not exist, that virtual host will inherit the document root from the server context (the server will start).

This directive controls whether httpd may use the sendfile support from the kernel to transmit file contents to the client. By default, when the handling of a request requires no access to the data within a file (for example, when delivering a static file) Apache uses sendfile to deliver the file contents without ever reading the file if the operating system supports it. This sendfile mechanism avoids separate read and send operations, and buffer allocations.

In the event of a problem or error, HTTP Server can be configured to do one of four things:

1. Output a simple hard coded error message.
2. Output a customized message.
3. Redirect to a local URL to handle the problem/error.
4. Redirect to an external URL to handle the problem/error.

The first option is the default, while options 2 through 4 are configured using the ErrorDocument directive, which is followed by HTTP Server response code and a message or URL.

For option 3, the document parameter must begin with a '/' character and it is assumed to be relative to DocumentRoot. If the document parameter contains a ':' character it is assumed to be an external URL (option 4). If neither of these are true, option 2 is assumed.

Parameter One: error-code

• The error-code parameter specifies the error code associated with a hard coded error message, a customized message, a local URL, or an external URL that handles the problem/error.

Parameter Two: document

• The document parameter specifies a hard coded error message, a customized message, a local URL, or an external URL that handles the problem/error.

Messages in this context begin with a single quote ("), which does not form part of the message itself. The server will sometimes offer additional information regarding the problem/error.

URLs must begin with a slash (/) for local URLs, or be a full URL which the client can resolve. For example:

ErrorDocument 500 http://QIBM.example.com/cgi-bin/tester 
ErrorDocument 404 /cgi-bin/bad_urls.html 
ErrorDocument 401 /subscription_info.html 
ErrorDocument 403 "Sorry cannot allow you access today.   

IBM HTTP Server for i allows error code keywords on this directive, in addition to HTTP response codes. This will allow customers more granularity in their error page customization. To do this, the syntax for ErrorDocument was enhanced to also allow one of these key words as the error_code. Valid keywords, their equivalent HTTP response codes and the cause are as follows:

An example - a customer puts the following into their configuration file:

ErrorDocument byrule "Sorry cannot allow you access." 
ErrorDocument openfailed "You do not have authority to this file." 

When an HTTP response code of 403 (FORBIDDEN) occurs and it is determined that the reason is the client is on the deny list, the response back to the browser will be "Sorry cannot allow you access". If, however, the 403 response code is a result of the user not having authority to the file, the message will be "You do not have authority to this file". This gives the user more granularity to customize error responses to the client.

The ErrorLog directive sets the name of the file to which the server will log any errors it may encounter. If the filename does not begin with a slash (/) then it is assumed to be relative to the ServerRoot. Specifying a value of off or *off will cause the server to not log errors.

Parameter: filename-or-pipe | off | *off

• The filename parameter is relative to the ServerRoot or a full path to the file.
• A pipe (|) followed by a program to spawn to handle the error log information. Data written to the pipe from the server will be in the FSCCSID that is in use by the server.
• The off or *off value turns off error reading.

All messages logged to the Error log will be logged in the primary language installed for the IBM HTTP Server. The error log file will be created with a coded character set identifier (CCSID) that is compatible with the language. The CCSID value is an ASCII CCSID.

It is recommended that you allow the server to create the log file. Specifically:

• For IFS files, the user must create the directories that contain the log file and must grant the QTMHHTTP user write access to the directory. The server will create the log file.
• For QSYS.LIB logs, the user must create the library that contains the logs. The server will create the file and members in the specified library.
• If the filename does not begin with a slash (/) then it is assumed to be relative to the ServerRoot.
• If LogCycle is active and if the path ends without a '/' character, then the path is considered to be the complete log file name. In that case, the server will add an extension in the format QCYYMMDDHH, where these variables have the following values:
  • Q is a default value that indicates to the server that this is a log file.
  • C is the century indicator (0 for pre-2000, 1 for post-2000)
  • YY is the year indicator
  • MM is the month indicator
  • DD is the day indicator HH is the hour indicator (00 = 00:00 (midnight), 23=23:00)
    Note: Will not be generated for file system QDL.

    For example, a path of "/logs/errorlog" results in a file such as "/logs/errorlog.Q100030300".

• If LogCycle is active and if the path ends with a '/' character, then the path is considered to be the directory that will contain the log file. In that case, the server will create log files named in the QCYYMMDDHH format. For example, a path of "/logs/errorlog/" results in a file such as "/logs/errorlog/Q100030300".
• If LogCycle is active and the log file is in the QSYS file system, the name must end it the file component of the IFS path. Example:

  # Config file directives
  LogCycle Daily
  ErrorLog /QSYS.LIB/MYLIB.LIB/MYLOGS.FILE

  The resulting daily log rollover files will be of the form /QSYS.LIB/MYLIB.LIB/MYLOGS.FILE/Qcyymmddhh.MBR

• LogCycle Hourly is not valid if the log file is in the QDLS file system as that file system only supports 8 character file names and 3 character extensions.
• If LogCycle is not active, no special naming is used. The name of the log file given on the ErrorLog directive is used as given for the name of the log file. If the name is a directory, a default name of http.log will be concatenated to the directory name to create the log file. For example:

  # Config file directives 
  LogCycle Off 
  LogFormat "%h %l %u %t \"%r\" %>s %b" common 
  CustomLog /logs/path/ common 

  The resulting log file will be /logs/path/http.log.

Security:

See Security tips for HTTP Server details on why your security could be compromised if the directory where log files are stored is writable by anyone other than the user that starts the server. If a program is used, then it will be run under the user who started httpd. This will be root if the server was started by root (be sure that the program is secure).

See also LogLevel.

The ErrorLogFormatDDS directive is used to specify whether the server should log information to the ErrorLog in the IBM i data description specification (DDS) format. This directive provides equivalent error logging function to the HTTP Server (original) DDS LogFormat.

If the parameter is set to on, the server creates a DDS log file and each record contains the format described by file QHTTPSVR/QAZHBERR. When the parameter is on, the path name specified on the ErrorLog directive must be the internal file system syntax for a file in the QSYS.LIB file system, or a server start up error results. To view a description of the fields within a log file created with DDS format, use the command DSPFFD FILE(QHTTPSVR/QAZHBERR).

By default, the IBM i logs is in Apache's standard ErrorLog format.

The FileETag directive configures the file attributes that are used to create the ETag (entity tag) response header field when the document is based on a file. The ETag value is used in cache management to save network bandwidth. In Apache 1.3.22 and earlier, the ETag value was always formed from the file's inode, size, and last-modified time (mtime). The FileETag directive allows you to choose which of these (if any) should be used.

Parameter: component

• INode indicates the file's inode number will be included in the calculation.
  Note: INode is the file ID number for the object. This number uniquely identifies the object within a file system. It is part of the stat structure (the st_ino field of the stat structure).
• MTime indicates the date and time the file was last modified will be included.
• Size indicates the number of bytes in the file will be included.
• All indicates all available fields will be used (equivalent to 'FileETag INode MTime Size').
• None indicates that if a document is file-based, no ETag field will be included in the response.

The INode, MTime, and Size keywords may be prefixed with either '+' or '-', which allow changes to be made to the default setting inherited from a higher level context. Any keyword appearing without such a prefix immediately and completely cancels the inherited setting.

If a directory's configuration includes 'FileETag INode MTime Size', and a subdirectory's includes 'FileETag -INode', the setting for that subdirectory (which will be inherited by any sub-subdirectories that don't override it) will be equivalent to 'FileETag MTime Size'.

The MTime attribute (if specified) may be used by remote proxy servers to calculate cache expiry times in the event that document expiry times are not available or provided.

See CacheLastModifiedFactor for more information.

The <Files> directive provides for access control by filename. It is comparable to the <Directory> directive and <Location> directives. It should be matched with a </Files>. Directives given within this section will be applied to any object with a base-name (last component of filename) matching the specified filename. <Files> sections are processed in the order they appear in the configuration file, after the <Directory> sections and .htaccess files are read, but before <Location> sections. Note that <Files> can be nested inside <Directory> sections to restrict the portion of the file system.

Parameter: filename

• The filename parameter should include a filename or a wildcard string where '?' matches any single character and '*' matches any sequences of characters. For example:

  <Files index.html>
     Order allow,deny
     allow from all
  </Files>

• Extended regular expressions can also be used, with the addition of the '~' character.

The <FilesMatch> directive provides for access control by filename, in the same way <Files> directive does. The <FilesMatch> directive, however, accepts a regular expression. For example:

<FilesMatch "\.(gif|jpe?g|png)$">

This would match most common Internet graphic formats.

Parameter: regex

• Regex is a UNIX-style regular expression that is matched against the URL. Subexpressions are grouped within parentheses. Then, parenthetically enclosed regular expressions will be substituted in a subsequent $n statement.

The ForceType directive forces all matching files to be served as the content type given by media type when they are placed into an .htaccess file, a <Directory>, or <Location> section.

Parameter: media_type

• The media_type parameter is a MIME type/subtype to which all files in the directory will be forced.

This module provides for forensic logging of client requests. Logging is done before and after processing a request, so the forensic log contains two log lines for each request. The forensic logger is very strict. The format is fixed. You cannot modify the logging format at runtime. Each request is logged two times. The first time after receiving the headers. The second log entry is written after the request processing at the same time when normal logging occurs. To identify each request, a unique request ID is assigned. This forensic ID can be cross logged in the normal transfer log using the %{forensic-id}n format string. If you are using mod_unique_id its generated ID will be used.

The first line logs the forensic ID, the request line and all received headers, separated by pipe characters (|). A sample line follows:

+yQtJf8CoAB4AAFNXBIEAAAAA|GET /manual/de/images/down.gif HTTP/1.1|Host:localhost%3
a8080|User-Agent:Mozilla/5.0 (X11; U; Linux i686; en-US; rv%3a1.6) Gecko/20040216
Firefox/0.8|Accept:image/png 

Note: The examples are wrapped for display purposes only.

The plus character at the beginning indicates that this is first log line of this request. The second line just contains a minus character and the id again:

-yQtJf8CoAB4AAFNXBIEAAAAA

The check_forensic script takes as its argument the name of the logfile. It looks for the ± ID pairs and issues an error if a request was not completed.

The HostNameLookups directive enables DNS lookups so the host names can be logged (and passed to CGIs/SSIs in the REMOTE_HOST environment variable).

Parameter: on | off | double

• The on value enables DNS lookups so the host names can be logged (and passed to CGIs/SSIs in the REMOTE_HOST environment variable).
• The default off value saves on the network traffic for those sites that do not truly need the reverse lookup. Heavily loaded sites should leave this directive set to off, since DNS lookups can take a considerable amount of time.
• The value double refers to doing double-reverse DNS. That is, after a reverse lookup is performed, a forward lookup is then performed on that command. At least one of the IP addresses in the forward lookup must match the Original address. When mod_access is used for controlling access by hostname, regardless of the setting, a double reverse lookup will be performed. This is necessary for security.

The HotBackup directive is used to specify whether or not a hot backup server should be started at the server startup time. With the hot backup server active, if the primary server job abnormally terminates, the hot backup will immediately take over and act as the primary and continue servicing requests. A new hot backup is automatically created, in the background, within one minute. However, if more than five consecutive server failures occur within a ten minute time period, no additional hot backups will be created and the server will fail. The server is allowed to fail in this situation to avoid system degradation, since the hot backup processing can consume system resources.

If the primary server process failure is not due to the network, all user connections remain active during the hot backup take over and the end users do not detect the loss of server; however, some HTTP requests in transient may be lost. If the failure is due to the loss of network, the server must be restarted.

For a full backup recovery, including system and network failures, refer to highly available Web server.

Parameter: on | off

• When set to on, if the primary server job abnormally terminates, the hot backup will immediately take over and act as the primary and continue servicing requests.
• With HotBackup off, only one multithreaded server child process is started.

The HTTPSubsystemDesc directive specifies the user created subsystem that the HTTP server runs in. By default HTTP server runs under QHTTPSVR/QHTTPSVR subsystem.

The subsystem must already exist before using this directive, otherwise HTTP server will fail to start. The subsystem can be automatically started if it's not active when starting HTTP server but will not be ended when stopping the HTTP server

The HTTPStartJobQueue directive specifies the user created job queue to which the HTTP server jobs will be submitted. The default HTTP server job queue is QHTTPSVR/QZHBHTTP.

The job queue must already exist before using this directive, otherwise HTTP server will fail to start.

The HTTPStartJobDesc directive specifies the user created job description which defines how HTTP server jobs should be run. The default HTTP server job description is QHTTPSVR/QZHBHTTP.

The job description must already exist before using this directive, otherwise HTTP server will fail to start.

The HTTPRoutingData directive specifies the user defined routing data for HTTP server jobs. The default value is HTTPWWW. A maximum of 80 characters can be specified.

The routing entry must be already added to the HTTP subsystem before using this directive, otherwise HTTP server will fail to start.

The IdentityCheck directive enables compliant logging of the remote user name for each connection, where the client machine runs identd or something similar. This information is logged in the access log.

Parameter: on | off

• When set to on, the server will attempt to identify the client's user by querying the identd daemon of the client host. Identd will, when given a socket number, reveal which user created that socket. That is, the username of the client on his home machine. Since the information provided is entirely under the control of the client's machine, this information should not be trusted in any way except for rudimentary usage tracking.
• When set to off, the server does not attempt to identify the client's user.

A CustomLog, TransferLog or FRCACustomLog must be configured before this directive will take affect. If IdentityCheck is configured in a directory or location container, the CustomLog, TransferLog or FRCACustomLog must be configured in the server context where the directory or location container resides for it to take affect. Also for this directive to be used in the CustomLog, TransferLog, or FRCACustomLog, the LogFormat for these has to specify "%l" (lower case L) in the format.

See Module mod_log_config for information on log formats.

The <IfDefine test> ... </IfDefine> section is used to mark directives that are conditional. The directives within an IfDefine section are only processed if the test is true. If the test is false, everything between the start and end markers is ignored.

The test in the <IfDefine> section directive can be one of the two forms:

• parameter-name
• !parameter-name

In the former case, the directives between the start and end markers are only processed if the parameter named parameter-name is defined. The second format reverses the test, and only processes the directives if parameter-name is not defined.

Parameter: parameter-name

• The parameter-name parameter is defined as given on the STRTCPSVR command line vie -Dparameter, at the time the server was started. <IfDefine> sections are nestable, which can be used to implement simple mutliple-parameter tests. For example:

  STRTCPSVR '-DLDAP' 
  # in the instance configuration
  <IfDefine LDAP>
     LoadModule ldap_module /QSYS.LIB/QHTTPSVR.LIB/MOD_LDAP.SRVPGM
  </IfDefine>

If customer has included "<IfDefine keyword> ... </IfDefine> in http.conf file, the directives that are in context will be only valid if the command "STRTCPSVR" has included this directive, in this case " STRTCPSVR '-Dkeyword' ", if not, the server will ignored then.

The <IfModule> directive is used to mark directives that are conditional. The directives within an <IfModule> section are only processed if the test is true. If the test is false, everything between the start and end markers is ignored.

The test in <IfModule> section directive can be one of two forms:

• module-name
• !module-name

Parameter: module-name

• The module-name parameter is a module name as given as the file name of the module at the time it was compiled. For example:

  mod_rewrite.c 

<IfModule> sections are nestable which can be used to implement simple multiple-module tests.

The Include directive allows inclusion of other configuration files from within the server configuration files. The filename can be either a relative or absolute path.

Parameter: filename

• The filename value identifies other configuration files from within the server configuration files.

The KeepAlive directive enables keep-alive support (also known as persistent connections).

Parameter: on | off

• When set to on, the directive enables keep-alive support (also known as persistent connections).
• When set to off, keep-alive support (also known as persistent connections) is disabled.

Persistent connections enable a single TCP connection to be used for multiple HTTP requests. Normally, each HTTP request uses a separate connection. Reusing a single connection reduces the connection open/close overhead, thereby improving performance for that client. However with dynamic content, depending on your Web applications, using persistent connections can reserve server resources for each client, thereby reducing the throughput of your server as a whole. Therefore, care should be taken when modifying persistent connection related settings.

Set to off to disable persistent connections, on to enable. If the KeepAlive directive value is not off or zero, on is assumed.

See also KeepAliveTimeout and MaxKeepAliveRequests.

The KeepAliveTimeout directive is related to persistent connections and determines the number of seconds HTTP Server waits for a subsequent request before closing the connection. The KeepAlive directive must be set to on, enabling persistent connections, for this directive to take effect. It is recommended that this value be set high enough to prevent time outs. Note that this is related to the time between requests and not during requests. Once a request is received, the connection timeout setting (set by the TimeOut directive) applies. The connection time-out applies until request processing is complete and (until the next request is received) the persistent connections related timer setting is applied.

Parameter: seconds

• The seconds value determines the number of seconds HTTP Server waits for a subsequent request before closing the connection.

See also KeepAlive, MaxKeepAliveRequests, and TimeOut.

The purpose of the <Limit> directive is to restrict the effect of the access controls to the nominated HTTP methods. For all other methods, the access restrictions that are enclosed in the <Limit> bracket will have no effect. The following example applies the access control only to the methods POST, PUT, and DELETE, leaving all other methods unprotected:

<Limit POST PUT DELETE>
   require valid-user
</Limit>

Access controls are normally effective for all access methods, and this is the usual desired behavior. In the general case, access control directives should not be placed within a <Limit> section.

Parameter: method

• Method names listed can be one or more of the following: GET, POST, PUT, DELETE, CONNECT, OPTIONS, PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK and UNLOCK. The method name is case sensitive. If GET is used it will also restrict HEAD requests.

<LimitExcept> and </LimitExcept> are used to enclose a group of access control directives which will then apply to any HTTP access method not listed in the arguments; for example, it is the opposite of a <Limit> section and can be used to control both standard and nonstandard-unrecognized methods. See <Limit> for more details.

Parameter: method

• Method names listed can be one or more of the following: GET, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK and UNLOCK. The method name is case sensitive. If GET is specified, HEAD is also allowed (not restricted).

The LimitRequestBody directive allows the user to set a limit on the allowed size (in bytes) of an HTTP Request message body within the context in which the directive is given (server, per-directory, per-file or per-location). If the client Request exceeds that limit, the server will return an error response instead of servicing the Request. The size of a normal Request message body will vary greatly depending on the nature of the resource and the methods allowed on that resource. CGI scripts typically use the message body for passing form information to the server. Implementations of the PUT method will require a value at least as large as any representation that the server wants to accept for that resource.

This directive gives the server administrator greater control over abnormal client Request behavior, which may be useful for avoiding some forms of denial-of-service attacks.

Parameter: number

• The number parameter is an integer which represents the set limit on the allowed size (in bytes) of an HTTP Request message body within the context in which the directive is given (server, per-directory, per-file or per-location). The default value of '0' (zero) indicated unlimited allowed size.

For example, to limit the size of an uploaded file to 100K use the following:

LimitRequestBody 10240

An internal redirect happens, for example, when using the Action directive, which internally redirects the original request to a CGI script. A subrequest is Apache's mechanism to find out what would happen for some URI if it were requested. For example, mod_dir uses subrequests to look for the files listed in the DirectoryIndex directive.

LimitInternalRecursion prevents the server from crashing when entering an infinite loop of internal redirects or subrequests. Such loops are usually caused by misconfigurations. The directive stores two different limits, which are evaluated on per-request basis. The first number is the maximum number of internal redirects, that may follow each other. The second number determines, how deep subrequests may be nested. If you specify only one number, it will be assigned to both limits.

The LimitRequestFields directive allows the server administrator to modify the limit on the number of Request header fields allowed in an HTTP Request. A server needs this value to be larger than the number of fields that a normal client Request might include. The number of Request header fields used by a client rarely exceeds 20, but this may vary among different client implementations, often depending upon the extent to which a user has configured their browser to support detailed content negotiation. Optional HTTP extensions are often expressed using Request header fields.

This directive gives the server administrator greater control over abnormal client Request behavior, which may be useful for avoiding some forms of denial-of-service attacks. The value should be increased if normal clients see an error response from the server that indicates too many fields were sent in the Request.

Parameter: number

• The number parameter is an integer from 0 (meaning unlimited) to 32767 bytes. The default value is 100.

The LimitRequestFieldsize directive allows the server administrator to reduce the limit on the allowed size of an HTTP Request header field below the normal input buffer size compiled with the server. A server needs this value to be large enough to hold any one header field from a normal client Request. The size of a normal Request header field will vary greatly among different client implementations, often depending upon the extent to which a user has configured their browser to support detailed content negotiation.

This directive gives the server administrator greater control over abnormal client Request behavior, which may be useful for avoiding some forms of denial-of-service attacks. Under normal conditions, the value should not be changed from the default.

Parameter: number

• A number is an integer from 0 to 32766 (in bytes).

The LimitRequestLine directive allows the server administrator to reduce the limit on the allowed size of a client's HTTP Request-line below the normal input buffer size compiled with the server. Since the Request-line consists of the HTTP method, URI, and protocol version, the LimitRequestLine directive places a restriction on the length of a Request-URI allowed for a Request on the server. A server needs this value to be large enough to hold any of its resource names, including any information that might be passed in the query part of a GET Request.

This directive gives the server administrator greater control over abnormal client Request behavior, which may be useful for avoiding some forms of denial-of-service attacks. Under normal conditions, the value should not be changed from the default.

Parameter: number

• A number is an integer from 0 to 8190 (in bytes).

The LimitXMLRequestBody directive limits (in bytes) the maximum size of an XML-based request body.

Parameter: number

• A number is an integer from 0 (meaning unlimited) to 2,147,483,647 (2 gigabytes).

The Listen directive instructs HTTP Server to listen to more than one IP address or port; by default the server responds to requests on all IP interfaces. It tells the server to accept incoming requests on the specified IP address or address-and-port combinations. If the first format is used, with an IP address number only, the server listens to the given IP address. If an IP address is given as well as a port, the server will listen on the given port and interface.

Parameter One: IP address

• The IP address parameter specifies a fully qualified IP address.

Parameter Two: port number

• The port number parameter is optional and if specified as word "FRCA", implies the incoming connections on the specified IP address and port are eligible to be monitored and served by FRCA cache support.
  Note: FRCA does not support SSL. Therefore, do not specify FRCA option for IP addresses and ports that are used for SSL connections.

Parameter Three: [protocol]

• The [protocol] parameter is optional and if specified as word "FRCA", implies the incoming connections on the specified IP address and port are eligible to be monitored and served by FRCA cache support.
  Note: FRCA does not support SSL. Therefore, do not specify FRCA option for IP addresses and ports that are used for SSL connections.

Multiple Listen directives may be used to specify a number of addresses and ports to listen to. The server will respond to requests from any of the listed addresses and ports.

To make the server accept connections on both port 80 and port 8000, use:

Listen 80 
Listen 8000

To make the server accept connections on two specified interfaces and port numbers, use:

Listen 194.170.2.1:80 
Listen 194.170.2.5:8000

IPv6 addresses must be surrounded in square brackets, as in the following example:

Listen [2001:db8::a00:20ff:fea7:ccea]:80 

To make the FRCA monitor and intercept connections on a specified interface and port numbers, use:

Listen 194.170.2.5:8000 FRCA

In the above example, since the optional parameter FRCA is specified, FRCA will be enabled for the specified IP address and port.

Listen 192.170.2.1:8443 https

Error condition: Multiple Listen directives for the same ip address and port will result in an Address already in use error message.

The ListenBacklog sets the maximum length of the queue for pending connections. Generally no tuning is needed; however, on some systems it is desirable to increase this when under a TCP SYN flood attack.

Parameter: backlog

• The backlog parameter is an integer value that sets the maximum length of the queue for pending connections.

The <Location> directive limits the scope of the enclosed directives by URL (the URL is the virtual path used to access a resource), and is similar to the <Directory> and <Proxy> directives, and starts a subsection which is terminated with a </Location> directive. Everything that is syntactically allowed in <Directory> is also allowed in <Location> (except a sub-<Files> section). However some directives, most notably the AllowOverride directive and two of its options (FollowSymLinks and SymLinksIfOwnerMatch) do not belong in <Location>. <Location> sections are processed in the order they appear in the configuration file (as opposed to <Directory> sections which are processed from the least match to the best match). They are processed after the <Directory> and <Proxy> sections, after .htaccess files are read, and after the <Files> sections. See <Directory>, <Proxy>, <Files>, and AllowOverride directives for more information on <Directory>, <Proxy>, and <Files> containers and access files.

Parameter : url

• The url parameter consists of a URL.

  For all origin (non-proxy) requests, the URL to be matched is of the form /path/. The URL should not include the http://servername prefix. For proxy requests, the matched URL is of the form http://servername/path (you must include the prefix).

  The URL may use wildcards in a wildcard string. '?' matches any single character; '*' matches any sequence of characters.

Extended regular expressions can also be used, with the addition of the ~ character. For example:

<Location ~ "/(extra|special)/data">

This would match URLs that contained the substring "/extra/data" or "/special/data". The directive <LocationMatch> behaves identical to the regex version of <Location>. The <Location> functionality is especially useful when combined with the SetHandler directive. For example, to enable origin requests, but allow them only from browsers at QIBM.com, you might use:

<Location /Origin>
   SetHandler server-Origin
   order deny,allow
   deny from all
   allow from .QIBM.com
</Location>

The <LocationMatch> directive provides for access control by URL. This directive works in an identical manner to the <Location> directive. However, it takes a regular expression as an argument instead of a simple string.

Parameter: regex

• The regex parameter is a UNIX-style regular expression that is matched against the URL.

For example:

<LocationMatch "/(extra|special)/data">

This would match URLs that contained the substring "/extra/data" or "/special/data".

The LogCycle directive controls the server's log cycle. This refers to how often the server will close all log files and open new files with a new date/time stamp.

Parameter: Off | Hourly | Daily | Weekly | Monthly

• If Off is specified, one continuous log file is generated. Log files are not rolled over.
• If Hourly is specified, log files are closed and a new one created at the end of each hour.
• If Daily is specified, log files are closed and a new one created at midnight each day.
• If Weekly is specified, log files are closed and a new one created at midnight each Sunday morning. Weekly may not work correctly if the system is not using the Gregorian calendar (this would be similar to the help behind system value QDAYOFWEEK).
• If Monthly is specified, log files are closed and a new one created at midnight on the first day of the month.

If LogCycle is active and the path defined on an ErrorLog, CustomLog, TransferLog, or FRCACustomLog directive ends without a (/) character, then the path is considered to be the complete log file name. In that case, the server will add an extension to the given file with the format QCYYMMDDHH, where these variables have the following values:

• Q is a default value that indicates to the server that this is a log file.
• C is the century indicator (0 for pre-2000, 1 for post-2000)
• YY is the year indicator
• MM is the month indicator
• DD is the day indicator
• HH is the hour indicator (00 = 00:00 (midnight), 23=23:00)
  Note: HH will not be generated for file system QDLS.

For example, a path of "/logs/errorlog" results in a file such as "/logs/errorlog.Q100030300".

If LogCycle is active and the path defined on an ErrorLog, CustomLog, TransferLog, or FRCACustomLog directive ends with a (/) character, then the path is considered to be the directory that will contain the log file. In that case, the server will create log files named in the QCYYMMDDHH format. For example, a path of "/logs/errorlog/" created on March 3, 2001 results in a file such as "/logs/errorlog/Q101030300".

If LogCycle is active and the path defined on an ErrorLog, CustomLog, TransferLog, or FRCACustomLog directive is in the QSYS file system, the name must end with the file component of the IFS path. Fore example:

# Config file directives
LogCycle Daily
LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog /QSYS.LIB/MYLIB.LIB/MYLOGS.FILE common

The resulting daily log rollovers will be of the form /QSYS.LIB/MYLIB.LIB/MYLOGS.FILE/Qcyymmddhh.MBR.

If LogCycle is not active, no special naming is used. The name of the log file given on an ErrorLog, CustomLog, TransferLog, or FRCACustomLog directive is used as given for the name of the log file.

If LogCycle Weekly is specified, rollover will occur when QDAYOFWEEK is equal to *SUN. However, if the system is not using the Gregorian calendar, this value may not be set correctly and the logs may not get rolled over as expected.

LogCycle Hourly is not valid if the log file is in the QDLS file system as that file system only supports 8 character file names and 3 character extensions.

The LogLength directive limits the size of any defined log file. To prevent problems due to unbounded growth of log files, this directive can be used to set an maximum file-size for log files. If the file exceeds this size, no more information will be written to it until logs and alertable message HTP8433 will be sent to QSYSOPR. The server will automatically restart logging requests when the logs are rolled over to the next log cycle. This directive can be specified multiple times in the configuration file.

Parameter: number-of-bytes

• The number-of-bytes parameter is an integer value that sets the maximum size limit of the log file. When any defined log file ( those defined with CustomLog, TransferLog, FRCACustomLog, or ErrorLog directives) exceeds this value, no more information will be logged until log rollover occurs. An alertable message TCP7201 will be sent to QSYSOPR. A value of 0 means there is no limit. If 'LogCycle Off' is specified and a non-zero value is specified for LogLength, when the LogLength size is reached no more logging will be done (even on starts and restarts of the server instance) since the same file will be used every time.

The LogLevel directive adjusts the verbosity of the messages recorded in the error logs. See the ErrorLog directive for more information.

Parameter: level

The following levels are available, in order of decreasing significance:

• If emerg, system is unusable messages ("Child cannot open lock file. Exiting.").
• If alert, action must be taken immediately messages ("getpwuid: couldn't determine user name from uid.").
• If crit, critical conditions messages ("Socket: Failed to get socket, exiting child.").
• If error, error conditions messages ("Premature end of script headers.").
• If warn, warning conditions messages ("Child process 1234 did not exit, sending another SIGHUP."). If notice, normal but significant conditions messages ("httpd: caught SIGBUS, attempting to dump core in...").
• If info, informational messages ("Server seems busy, (you may need to increase StartServers or Min/MaxSpareServers)...").
• If debug, debug-level messages ("Opening config file...").

When a particular level is specified, messages from all other levels of higher significance will be reported as well. For example, when LogLevel info is specified, then messages with log levels of notice and warn will also be posted. Using a level of at least crit is recommended.

The LogMaint directive allows you perform log maintenance on the specified file and its derivatives. When log maintenance is performed on a file, it is purged from the system. Derivatives consist of either the path_to_file name provided, concatenated with the extension ".Qcyymmdd", or "Qcyymmdd" if the provided path_to_file value was a directory. LogCycle must be active in order to enable derivatives.

A separate LogMaint directive is required in the server configuration for each CustomLog or ErrorLog that requires log maintenance. The recommended way to configure maintenance is to match the path configured on the LogMaint directive with the path specified on the associated CustomLog or ErrorLog directive.

Parameter One: path_to_file

• The path_to_file value specifies the IFS-style path (for example, /QSYS.LIB/MYHTTP.LIB/MYLOGS.FILE) of the log file to be included in log maintenance. Refer to the LogCycle directive for more information on log file names and extensions.

Parameter Two: expire

• The expire value specifies an integer value indicating the number of days before a log file expires. Files older than this value are to be removed. A value of 0 means the log file will never expire. The age of the error log file is determined by the file creation date (as reported by the operating system). The file name suffix, such as errorlog.Q100082213, is not used to determine the age of the file. Files that are currently open and active in the server instance will not be removed.

Parameter Three: size_limit

• The size_limit value specifies an integer value indicating the maximum aggregate size of log files with the name path_to_file. When the combined size of the log files exceeds this value in bytes, files are deleted starting with the oldest file. Eligible files are deleted until the collective size is less than or equal to the value specified on this directive. A value of 0 means there is no size limit. Note that it is possible for the aggregate size of log files to exceed the total size_limit. This is possible due to the fact that the size of any open log files are not included in the size_limit total. Users should take this into account when they are calculating a value for size limit, and when setting a maximum value for the LogLength directive.

If both expire and size_limit are configured to non-zero values, the expired files are purged first. If the size_limits still exceeded after expired files are purged, the server continues purging files (oldest files first) until the collective log size is equal to or less than the size_limit.

The following example of log maintenance will be performed on the logs/access_log file and its derivatives (see below for details). The files will expire after 10 days. In addition, if the total limit exceeds 2,000,000 bytes, log maintenance will be performed.

LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog logs/access_log common
LogMaint logs/access_log 10 2000000

The following example of log maintenance will be performed on the /QSYS.LIB/MYHTTP.LIB/MYLOGS.FILE/Q* files. The files will expire after 25 days and there is no total limit on the size of the files.

LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog /QSYS.LIB/MYHTTP.LIB/MYLOGS.FILE common
LogMaint /QSYS.LIB/MYHTTP.LIB/MYLOGS.FILE 25 0

Only one occurrence of this directive can exist per server or virtual host container. If the directive occurs more than once, the last one specified in the server or virtual host is used.

The LogMaintHour directive may be used to control which hour of the day log maintenance occurs. The default is for log maintenance to occur at midnight. Log maintenance always occurs at the beginning of the hour. By using this directive, which hour of the day maintenance will occur can be controlled, to do maintenance in the early morning or in the evening after the normal work day is done.

The LogTime directive specifies whether your log should record entrees using local time or Greenwich Mean Time (GMT). This directive affects timestamps for log entries only.

Parameter: LocalTime | GMT

• LocalTime indicates the local time for log entry timestamps.
• GMT indicates the Greenwich Mean Time for log entry timestamp.

The MaxKeepAliveRequests directive limits the number of requests allowed per connection when KeepAlive is on. If it is set to 0, unlimited requests will be allowed.

Parameter: number

• The number parameter specifies an integer value that limits the number of requests allowed per connection when KeepAlive is on.

See KeepAlive, and KeepAliveTimeout.

The NameVirtualHost directive is a required directive if you want to configure name-based virtual hosts.

Parameter: address

• The address parameter consists of an IP address or hostname. Although address can be a hostname, it is recommended that you always use an IP address. For example:

  NameVirtualHost 10.22.33.44

With the NameVirtualHost directive you specify the address to which your name-based virtual host names resolve. If you have multiple name-based hosts on multiple addresses, repeat the directive for each address.

Optionally you can specify a port number on which the name-based virtual hosts should be used, for example:

NameVirtualHost 10.22.33.44:8080 

The Options directive controls which server features are available in a particular directory.

Parameter : option

• The option parameter can be set to one or more of the following:

  Option	Description
  None	None of the extra features are enabled.
  All	All options except for MultiViews. This is the default setting.
  ExecCGI	Execution of CGI scripts is permitted.
  Follow SymLinks	The server will follow symbolic links in this directory. Note: Even though the server follow the SymLink, it does not change the pathname used to match against <Directory> sections. This option gets ignored if set inside <Location> sections.
  Includes	Server-side includes are permitted.
  IncludesNOEXEC	Server-side includes are permitted, but the #exec command and #include of CGI scripts are disabled.
  Indexes	If a URL which maps to a directory is requested and there is no DirectoyIndex (for example, index.html) in that directory, then the server will return a formatted listing of the directory.
  MultiViews	Content negotiated MultiViews are allowed. See Content negotiation for HTTP Server for more information.
  SymLinksIfOwnerMatch	The server will only follow symbolic links for which the target file or directory is owned by the same user id as the link. Note: This option is ignored if set inside a <Location> sections.

Normally, if multiple Options could apply to a directory, then the most specific one is taken complete; the options are not merged. However if all the options on the Options directive are preceded by a + or - symbol, the options are merged. Any options preceded by a + are added to the options currently in force; any options preceded by a - are removed from the options currently in force.

For example, without any + and - symbols:

<Directory /web/docs> 
   Options Indexes FollowSymLinks 
</Directory> 
<Directory /web/docs/spec> 
   Options Includes 
</Directory>

Then only Includes will be set for the /web/docs/spec directory. However if the second Options directive uses the + and - symbols:

<Directory /web/docs> 
   Options Indexes FollowSymLinks 
</Directory> 
<Directory /web/docs/spec> 
   Options +Includes -Indexes 
</Directory>

Then the options FollowSymLinks and Includes are set for the /web/docs/spec directory.

The option +IncludesNOEXEC can be used instead of +Includes.  If the previous is specified, then the SSI Exec tag is not processed during SSI processing.

The ProfileToken directive creates a 32-byte value called the ProfileToken. This token is used the same way as a userid/password combination to identify/authenticate a user, and prevents passing these values in the clear. The ProfileToken value can be used on any of the IBM i security APIs that accept a ProfileToken as input.

Parameter: on | off

• If on is specified, and basic authentication is performed successfully, the userid/password is passed in by the user (only an IBM i user) to generate a ProfileToken. A ProfileToken is not generated if this parameter is set to off, or if basic authentication was not successful.

  The ProfileToken is accessible in a CGI program via the HTTP_AS_AUTH_PROFILETKN environment variable. The HTTP_AS_AUTH_PRFILETKN environment variable is not set if a ProfileToken is not generated.

  The ProfileToken is accessible in HTTP Server modules via the headers section ( r->headers_in field), which is an internal representation of the HTTP request structure. The profile token is stored as the AS_Auth_ProfileTkn header in the headers section. HTTP Server modules can then retrieve this ProfileToken and either use it, or pass it on to another application. The AS_Auth_ProfileTkn header is not created if a ProfileToken is not generated.

This directive selects which authenticated users can access a directory.

Parameter: entity-name entity entity...

• If require user userid userid, then only the named users can access the directory.
• If require group groupname groupname, then only users in the named groups can access the directory.
• If require valid-user, then all valid users can access the directory.

Require must be accompanied by AuthName and AuthType directives, and directives such as PasswdFile and GroupFile (to define users and groups) in order to work correctly. For example:

AuthType Basic 
AuthName "Restricted Directory" 
PasswdFile web/users 
GroupFile /web/groups 
require group admin 

Access controls which are applied in this way are effective for all methods. This is what is normally desired. If you want to apply access controls only to specific methods, while leaving other methods unprotected, then place the require statement into a <Limit> section.

Access controls can be used in a named protection setup. To implement a named protection setup, place all of the access control directives in a file. Use the Include directive to include the file in your <Directory>, <File>, or <Location> context. This allows users that want to use the same type of protection setup within multiple contexts to add an include statement inside of each context.

The RuleCaseSense directive is used to control how requested URLs are handled.

Parameter: on | off

• When on is specified, the URLs are treated as case sensitive. This means that an exact match with case is required.
• When off is specified, the URLs are treated as case insensitive. Paths on directives and requested URLs are internally converted to upper case before they are compared.

The default value for the case sensitivity is off. Rules that map the same value in different cases to different things, for example ABC to XYZ, will not work correctly when RuleCaseSense is off. This type of mapping is not recommended.

When using protection for any URL, it is recommended that you set this directive to off. This ensures that all variations in case for your URLs are protected. If you do not protect any of your site, then this directive can be either on or off.  Setting it to Off allows your users to specify any case on their URLs and enables them to see your site.

If you use the QOpenSys file system, you will have to be careful to match the case of your file system in your directives. You will also need to be aware that case differences matter when serving files from the case sensitive file system. You should only turn this directive on when absolutely necessary.

RuleCaseSense affects the processing of the incoming URL in the "URL Fixup" and "URL translation" server phases. These phases manipulate the incoming URL and do not necessarily relate to other directives. RuleCaseSense affects the following directives: Alias, AliasMatch, RewriteBase, RewriteCond, RewriteMap, RewriteRule, ScriptAlias, and ScriptAliasMatch

The Satisfy directive establishes access policy if both allow and require are used. The parameter can be either 'all' or 'any'. This directive is only useful if access to a particular area is being restricted by both username/password and client host address.

Parameter: any | all

• In this case, the default behavior all requires that the client passes the address access restriction and enters a valid username and password.
• With the any option, the client will be granted access if they either pass the host restriction or enter a valid username and password. This can be used to password restrict an area, but to let clients from particular addresses in without prompting for a password.

The Require directive has to indicate Satisfy is not required every time AuthType is used, but if "Satisfy Any" is used, then you must also use Allow, Require, AuthType AuthName and PasswdFile in order for the Satisfy to work correctly. For example:

Order allow,deny
Allow from All
Satisfy Any
AuthType Basic  
AuthName "Realm can go here" 
PasswdFile %%SYSTEM%% 
Require valid-user

See also mod_access.

The SendBufferSize directive tells the server to set the TCP buffer size to the number of specified bytes. The TCP send buffer size provides a limit on the number of outgoing bytes that are buffered by TCP. Once this limits reached, attempts to send additional bytes may result in the application blocking until the number of outgoing bytes buffered drops below this limit. The number of outgoing buffered bytes is decremented when the remote system acknowledges the sent data.

Parameter: bytes

• The bytes value is an integer that must be set to 0 or a value that is greater or equal to 512 (in bytes). If 0 is specified, the server will use the default TCP send buffer size that is configured for the IBM i server.

The ServerAdmin directive specifies the e-mail address to be used in trailing footer lines for hard coded error messages returned to clients. The specified value is used in hypertext link references generated by the server when "email" is specified for the ServerSignature directive.

Parameter: email-address

• The email-address parameter specifies a valid email address.

For example,

ServerAdmin www-admin@server.ibm.com

The ServerAlias directive allows servers to be accessible by more than one name. For example, HTTP Server might want to be accessible as ibm.org, or ftp.ibm.org, assuming the IP addresses pointed to the same server. In fact, one might want it so that all addresses at ibm.org were picked up by the server. This is possible with the ServerAlias directive placed inside the <VirtualHost> section.

Parameter: host

• The host parameter specifies a hostname. Note that you can use '*' and '?' as wildcard characters.

For example,

<VirtualHost 10.22.33.55> 
   ServerAdmin webmaster@host.QIBM.com 
   DocumentRoot /usr/web/host.QIBM.com 
   ServerName host.QIBM.com 
   ServerAlias ibm.com *.ibm.org 
   ErrorLog logs/host.QIBM.com-error_log 
   TransferLog logs/host.QIBM.com-access_log 
</VirtualHost>

You may need ServerAlias if you are serving local users who do not always include the domain name. For example, if local users are familiar with typing "www" or "www.physics" then you will need to add ServerAlias www www.physics. It isn't possible for the server to know what domain the client uses for their name resolution because the client doesn't provide that information in the request.

The ServerAlias directive sets the alternate names for a host, for use with name-based virtual hosts.

If multiple occurrences of this directive are configured in a container, only the last occurrence is processed. All other occurrences are ignored.

The ServerName directive sets the server hostname. This setting is used when creating redirection URLs. If it is not specified, the server attempts to deduce the server name from its own IP address; however, this may not work reliably or may not return the preferred hostname.

Parameter: fully-qualified-domain-name

• The fully-qualified-domain-name parameter sets the server hostname.

For example,

ServerName simple.example.com:80
<VirtualHost 10.1.2.3> 
   ServerAdmin webmaster@host.QIBM.com 
   DocumentRoot /usr/web/host.QIBM.com 
   ServerName host.QIBM.com 
   ErrorLog logs/host.QIBM.com-error_log 
   TransferLog logs/host.QIBM.com-access_log
</VirutalHost>

This would be used if the canonical (main) name of the actual machine were simple.example.com. If you are using name-based virtual hosts, the ServerName inside a <VirtualHost> section specifies what hostname must appear in the request's Host: header to match this virtual host.

This directive allows a port to be added to the server name. This allows an administrator to assign the canonical port at the same time that the canonical name is assigned. If no port is specified, HTTP Server implies port 80 for http:// and port 443 for https:// requests. This setting also specifies the server name used when trailing footer lines are added to hard coded error messages (see ServerSignature).

See also UseCanonicalName, NameVirtualHost and ServerAlias.

The ServerPath directive sets the legacy URL pathname for a host, for use with name-based virtual hosts.

Parameter: pathname

• The pathname parameter sets the legacy URL pathname for a host, for use with name-based virtual hosts.

For example, an HTTP server exists with two name-based virtual hosts. In order to match the correct virtual host a client must send the correct Host: header. Old HTTP/1.0 clients do not send such a header and the server has no clue what virtual host the client tried to reach (and serves the request from the primary virtual host). To provide as much backward compatibility as possible, create a primary virtual host that returns a single page containing links with an URL prefix to the name-based virtual hosts.

A request to the URL http://www.sub1.domain.tld/sub1/ is always served from the sub1-virtual host. A request to the URL http://www.sub1.domain.tld/ is only served from the sub1-virtual host if the client sent a correct Host: header. If no Host: header is sent, the client gets the information page from the primary host. Note that there is one exception: a request to http://www.sub2.domain.tld/sub1/ is also served from the sub1-virtual host if the client did not send a Host: header. The RewriteRule directives are used to make sure that a client who sent a correct Host: header can use both URL variants (for example, with or without the URL prefix).

The ServerRoot directive sets the directory in which the server lives. Typically it will contain the subdirectories conf/ and logs/. Relative paths for other configuration files are taken as relative to this directory.

The directory-path parameter must specify a path in either the root ('/') or QOpenSys file system.

Parameter: directory-path

• The directory-path parameter sets the directory in which the server lives.

The ServerSignature directive specifies if trailing footer lines are to be generated for hard coded error messages returned to clients. When requests pass through a chain of servers, this feature is useful to identify which server generated the error message. The default value is off.

Parameter: on | off | email

• If on is specified, trailing footer lines containing the server name and version information are added to hard coded error messages.
• If off is specified (the default), trailing footer lines are suppressed and only hard coded error messages are returned.
• If email is specified, trailing footer lines are added and look identical to those generated when on is specified, however the server name is also a hypertext link that references the server administrator's e-mail address.

The value used for server name is that specified by the ServerName directive of the serving virtual host or server. The value used for version information is that specified by the ServerTokens directive. The value used for server administrator's e-mail address is that specified by the ServerAdmin directive.

For example, the value used for server name is that specified by the ServerName directive of the serving virtual host or server. The value used for version information is that specified by the ServerTokens directive. The value used for server administrator's e-mail address is that specified by the ServerAdmin directive.

For example,

ServerAdmin www-admin@myserver.com
ServerSignature email

The ServerTokens directive specifies which form of the Server: header value is included in response headers sent to clients. The value may consist of a minimal description of the server, a description with a generic OS-type included, a description that includes information about compiled-in modules, or a simple product description.

Parameter: Major | Minor | Minimal | OS | Full | Prod

• If Major is specified, the server sends: "Server : Apache/2"
• If Minor is specified, the server sends: "Server : Apache/2.2"
• If Minimal is specified, the server sends: "Server: Apache"
• If OS is specified, the server sends: "Server: Apache (i5)"
• If Full is specified, the server sends: "Server: Apache (i5) MymMod/1.2"
• If Prod is specified, the server sends: "Server: Apache"

This setting also specifies the version information used when trailing footer lines are added to hard coded error messages (see ServerSignature).

The ServerUserID directive specifies the user profile that the HTTP Server will run under. This directive tells what user profile to use when starting the worker threads under the child process.

Parameter: user_profile

• The user_profile parameter must be a valid user profile. This profile must be authorized to all the directories, files, and other server resources accessed by the Web server unless the server is configured to swap to another profile for specific requests or directories.

  This directive is now valid in all contexts. If userid is set and authentication is performed in a context, and the UserID value is set to %%SERVER%%, then ServerUserID will be used for that context. The ServerUserID is inherited through all contexts unlike UserID. If authentication is performed and the UserID directive is set to something other than %%SERVER%%, then ServerUserID is overridden by the UserID. If authentication is not performed at all, then ServerUserID is used from the correct context. This allows for specific and unique user id security models for separate virtual hosts, locations, directories, files or .htaccess, allowing for more security control (specific access versus "global") over the resources served by the HTTP Server.

See also UserID.

The SetHandler directive forces all matching files to be parsed through the handler given by handler-name. . This happens when it is placed into an .htaccess file or a <Directory> or <Location> section. For example, if you had a directory you wanted to be parsed entirely as imagemap rule files, regardless of extension, you might put the following into an .htaccess file in that directory: See Handler for HTTP Server for more information

SetHandler imap-file 

Parameter: handler-name

• The handler-name parameter is the name of the handler that will parse files in this directory.

The SetInputFilter directive sets the filters that process client requests when they are received by the server. Parameter One: filter

Parameter: filter

• The filter parameter sets the filters that process client requests when they are received by the server.

For example,

<Directory /www/data/>
  SetInputFilter gzip
</Directory>

If more than one filter is specified, they must be separated by semicolons in the order in which they should process the content.

The order of the arguments determines the order in which the filters process the content. The first filter in the list processes content first, followed by the second in the list, and so on until all filters in the list have processed the content.

See the Apache HTTP Server Version 2.0 Filters documentation for more information regarding filters.

The SetOutputFilter directive sets the filters that process responses from the server before they are sent to the client.

Parameter: filter

• The filter parameter sets the filters that process responses from the server before they are sent to the client.

For example, the following configuration will process all files in the /www/data/ directory for server-side includes:

<Directory /www/data/>
  SetOutputFilter INCLUDES
</Directory>

If more than one filter is specified, they must be separated by semicolons in the order in which they should process the content.

The order of the arguments determines the order in which the filters process the content. The first filter in the list processes content first, followed by the second in the list, and so on until all filters in the list have processed the content.

See the Apache HTTP Server Version 2.0 Filters documentation for more information regarding filters.

Use this directive to specify the maximum number of threads per server child process. If the directive is not specified, the global HTTP Server setting for maximum number of servers is used. The shipped value is 40. You can view and change global HTTP Server settings using the Change HTTP Attributes (CHGHTTPA) command.

Parameter: number

• The number value is an integer value that specifies the maximum number of threads per server child process.

The TimeOut directive defines the amount of time (in seconds) HTTP Server will wait for:

1. The amount of time between receipt of TCP packets on a request.
2. The amount of time between ACKs on transmissions of TCP packets in responses.

Parameter: number

• The number value is an integer value that specifies defines the amount of time (in seconds) HTTP Server will wait.

This directive overrides the behavior of TRACE for both the core server and mod_proxy. When "on" is specified for the TraceEnable directive, TRACE requests are permitted per RFC 2616, which disallows any request body to accompany the request. Setting the TraceEnable directive to "off" causes the core server and mod_proxy to return a 405 (Method not allowed) error response to the client.

For testing and diagnostic purposes only, request bodies may be allowed by specifying "extended" for the TraceEnable directive. The core will restrict the request body to 64 KB (plus 8 KB for chunk headers if Transfer-Encoding: chunked is used). The core will reflect the full headers and all chunk headers with the response body. As a proxy server, the request body is not restricted to 64 KB.

Parameter: on | off | extended

• A value of on permits TRACE requests.
• A value of off causes TRACE requests to return a 405 (Method not allowed) error response to the client.
• A value of extended permits TRACE requests that are not compliant for testing and diagnostic purposes.

In many situations HTTP Server has to construct a self-referential URL. That is, a URL that refers back to the same server.

Parameter: on | off | DNS

• When set to on, HTTP Server will use the ServerName directive to construct a canonical name for the server. This name is used in all self-referential URLs, and for the values of SERVER_NAME and SERVER_PORT environment variables in CGIs.
• When set to off, HTTP Server will form self-referential URLs using the hostname and port supplied by the client if any are supplied (otherwise it will use the canonical name). These values are the same that are used to implement name based virtual hosts, and are available with the same clients. The CGI variables SERVER_NAME and SERVER_PORT will be constructed from the client supplied values as well.

  An example where this may be useful is on an intranet server where you have users connecting to the machine using short names such as www. You'll notice that if the users type a shortname, and a URL which is a directory, such as http://www/splat, without the trailing slash then HTTP Server will redirect them to http://www.domain.com/splat/. If you have authentication enabled, this will cause the user to have to reauthenticate twice (once for www and once again for www.domain.com). But if UseCanonicalName is set off, then HTTP Server will redirect to http://www/splat/.

• The DNS setting is intended for use with mass IP-based virtual hosting to support clients that do not provide a Host: header. With this option HTTP Server does a reverse DNS lookup on the server IP address that the client connected to in order to work out self-referential URLs.

See also ServerName.

This directive instructs the HTTP Server to use shutdown on the socket connections.

<VirtualHost 10.1.2.3>
ServerAdmin webmaster@host.foo.com
DocumentRoot /www/docs/host.foo.com
ServerName host.foo.com
ErrorLog logs/host.foo.com-error_log
TransferLog logs/host.foo.com-access_log
</VirtualHost> 

<VirtualHost [2001:db8::a00:20ff:fea7:ccea]>
ServerAdmin webmaster@host.example.com
DocumentRoot /www/docs/host.example.com
ServerName host.example.com
ErrorLog logs/host.example.com-error_log
TransferLog logs/host.example.com-access_log
</VirtualHost> 

The term Virtual Host refers to the practice of running more than one web site (such as www.company1.com and www.company2.com) on a single machine. Virtual hosts can be "IP-based", meaning that you have a different IP address for every web site, or "name-based", meaning that you have multiple names running on each IP address. The fact that they are running on the same physical server is not apparent to the end user.

Parameter One: address

• The address parameter specifies a fully qualified IP address or hostname.

Parameter Two: port

• The port parameter specifies a port number. This parameter is optional. If a port is not specified the server port will be used.

<VirtualHost> and </VirtualHost> are used to enclose directives that apply only to a particular virtual host. Any directive that is allowed in a virtual host context may be used. When the server receives a document request on a particular virtual host, it uses the configuration directives enclosed in the <VirtualHost> section. The address parameter may be one of the following:

• The IP address of the virtual host.
• A fully qualified domain name for the IP address of the virtual host.
• The character *, which is used only in combination with NameVirtualHost * to match all IP addresses.
• The string _default_, which is used only with IP virtual hosting to catch unmatched IP addresses.

Each Virtual Host must correspond to a different IP address, different port number or a different host name for the server. In the former case, the server machine must be configured to accept IP packets for multiple addresses.

IPv6 addresses must be specified in square brackets because the optional port number could not be determined otherwise.

NameVirtualHost *:80
<VirtualHost *:80>
ServerName www.domain.tld 
ServerAlias domain.tld *.domain.tld
DocumentRoot /www/domain
</VirtualHost>

<VirtualHost *:80>
ServerName www.otherdomain.tld
DocumentRoot /www/otherdomain
</VirtualHost>

ServerAlias domain.tld *.domain.tld