[next] [previous] [contents] [full-page]8.1 - Service Directives
8.2 - Directive Detail
8.3 - Administration
8.4 - Examples
NOTE
The service configuration file is optional. If the HTTPD$SERVICE logical is not defined or the file does not exist service configuration is made using the HTTPD$CONFIG [Service] directives. For simple sites, those containing one or two services, the use of a separate service configuration file is probably not warranted. Once the number begins to grow this file offers a specific management interface for those services.
Precedence of service specifications:
In common with other configuration files, directives associated with a specific virtual services are introduced using a double-bracket delimited host specification (see 6.3 - Virtual Services). When configuring a service the following three components specify its essential characteristics.
A generic service is one that specifies a scheme and/or port
but no specific host name. This is useful in a cluster where multiple systems
all provide a basic service (e.g. a port 80 service). If the host name is
omitted or specified as an asterisk the service substitutes the system's IP
host name. See 8.4 - Examples.
SSL Services
Multiple virtual SSL services (https:) sharing the same certificate can essentially be configured against any host name (unique IP address or alias) and/or port in the same way as standard services (http:). Services requiring unique certificates can only be configured for the same port number against individual and unique IP addresses (i.e. not against aliases). This is not a WASD restriction, it applies to all servers for significant SSL technical reasons (see 14 - Secure Sockets Layer).
For example, unique certificates for https://www.company1.com:443/ and
https://www.company2.com:443/ can be configured only if COMPANY1 and COMPANY2
have unique IP addresses. If COMPANY2 is an alias for COMPANY1 they must share
the same certificate. During startup service configuration the server checks
for such conditions and issues a warning about "sharing" the service
with the first configured.
8.1 - Service Directives
Where a service directive has an equivalent configuration directive (e.g. error report path) the service directive takes precedence. This allows specific virtual services to selectively override the generic configuration.
|
Specifies the scheme, host name (or asterisk) and port of a service.
Specifies the HTML <BODY> tag for server error and other report pages. This allows some measure of site "look-and-feel" in page colour, background, etc. to be maintained.
Specifies the URL-format path to an optional, error reporting SSI document or script. See 6.4 - Error Reporting. This path can subsequently be remapped during request processing.
If the system has a multi-homed network interface this binds the service to the specific IP address and not to INADDR_ANY. Generally this will not be necessary.
When request logging is enabled then by default all services are logged. This directive allows logging to be suppressed for this service.
When use tracking is enabled then by default all requests on non-proxy services are tracked. This directive allows tracking to be suppressed for this service.
Enables and disables proxy request processing for this service. For proxy serving detail see 13 - Proxy Services.
Makes a proxy service require authorization before a client is allowed access via it. none disables authorization. PROXY enables HTTP proxy authorization. LOCAL enables standard server authorization. See 13.1.4 - Controlling Proxy Serving.
Enables and disables proxy caching for a proxy service.
Specifies the next proxy host if chained.
When user tracking is enabled only non-proxy services have it applied by default. This directive allows proxy service usage tracking to be enabled.
Specifies the service as providing proxying of SSL requests. This is sometimes refered as a "connect" service.
Specifies the location of the SSL certificates (VMS file specification). See 14.1 - SSL Configuration.
Specifies the location of the SSL private key (VMS file specification).
A service configuration file can be maintained using a simple text editor and HTTPD$SERVICE.
Alternatively the server administration menu may be used. See 15 - Server Administration. When using this interface for the first time ensure the HTTPD$SERVICE logical is correctly defined. If the file did not exist at server startup any services will have been created from the HTTPD$CONFIG [Service] directive. These will be displayed as the existing services and will be saved to the configuration file the first time it is saved.
Not all configuration directives may be shown depending on the type of service. For instance, unless a service is configured to provide proxy, only the [ServiceProxy] directive is displayed. To fully configure such a service enable it as proxy, save the file, then reload it. The additional directives will now be available.
There is always one empty service displayed each time the configuration
menu is generated. This information may be changed appropriately and then
saved to add new services to the configuration (of course, these will not be
available until the server is restarted). To configure multiple new services
add one at a time, saving each and reloading the file to provide a new blank
service.
8.4 - Examples
[[http://alpha.wasd.dsto.defence.gov.au:80]] [[http://alpha.wasd.dsto.defence.gov.au:8080]] [ServiceProxy] enabled [ServiceProxyAuth] PROXY [ServiceProxyCache] enabled [ServiceProxySSL] enabled [[https://alpha.wasd.dsto.defence.gov.au:443]] [ServiceSSLcert] ht_root:[local]alpha.pem
[[http://*:80]]If a cluster of four systems, ALPHA, BETA, GAMMA and DELTA all use this configuration each will have a service accessable via the following four URLs.
http://alpha.domain.name/ http://beta.domain.name/ http://gamma.domain.name/ http://delta.domain.name/