IBM HTTP Server Questions and Answers

Questions which apply to all levels of IBM HTTP Server

What release of Apache is IHS based on?

IHS release corresponding Apache release that it was based on corresponding Websphere Application Server release
1.3.12.x 1.3.12 3.5.x
1.3.19.x 1.3.20 4.0.x
1.3.26.x 1.3.26 5.0.x
1.3.28.x 1.3.28 5.1.x
2.0.42 2.0.42 5.0
2.0.42.1 2.0.44 Fix pack 5.0.1
2.0.42.2 2.0.46 Fix pack 5.0.2
2.0.42.2-PQ85834 and later 2.0.47 N/A
2.0.47 and later 2.0.47 5.1
6.0 and later 2.0.47 6.0.x

What about Websphere keep-alive vs. IHS keep-alive?

IHS keepalive settings affect connections between IHS and the web client. Websphere settings affect connections between the Websphere plug-in (running in IHS) and Websphere. The connections are independent and the settings are independent.

Requests handled by WebSphere plug-in aren't authenticated. WebSphere plug-in doesn't send user id to WebSphere. Why not?

When enabling authentication in IHS, be aware that some configuration mechanisms apply only to static files served by IHS but not to requests handled by the WebSphere plug-in.

Example 1:

<Directory /usr/HTTPServer/htdocs/en_US>
AuthType Basic
AuthName WebAccess
AuthUserFile /usr/HTTPServer/userids
Require valid-user
</Directory>

This type of configuration only affects files served by IHS. It does not affect WebSphere requests.

Example 2:

<Location />
AuthType Basic
AuthName WebAccess
AuthUserFile /usr/HTTPServer/userids
Require valid-user
</Location>

This type of configuration affects any request served by IHS, including WebSphere requests. The WebSphere plug-in would then pass the user id on to WebSphere for possible use by the application.

Why does web browser present an authentication prompt twice when loading the same page?

Watch out for redirections which make the web browser think it is contacting a different web server. Here is an example of this type of problem, where the web browser has to authenticate over non-SSL only to find out that it has been redirected to an SSL port. The browser assumes that it is a different server and will prompt again.

<Location /protected.html>
RewriteEngine on
RewriteCond %{SERVER_PORT} =80
RewriteRule ^(.*) https://%{SERVER_NAME}%{REQUEST_URI}
Satisfy all
AuthUserFile /etc/webusers
AuthName Intranet
AuthType basic
Require valid-user
</Location>

In this type of situation, the redirection to SSL should be unauthenticated. Then, the authentication should happen once the request has been issued to the SSL port. Here is a solution:

# when request for the protected resource is received over 
# non-SSL, redirect to SSL without authenticating
<VirtualHost *:80>
...       (existing configuration for this vhost)
<Location /protected.html>
RewriteEngine on
RewriteRule ^(.*) https://%{SERVER_NAME}%{REQUEST_URI}
</Location>
</VirtualHost>

# when request for the protected resource is received over
# SSL, authenticate
<VirtualHost *:443>
...       (existing configuration for this vhost)
<Location /protected.html>
Satisfy all
AuthUserFile /etc/webusers
AuthName Intranet
AuthType basic
Require valid-user
</Location>
</VirtualHost>

How to log a response header field such as Set-Cookie?

This is with the LogFormat directive. The format string to use is "%{header-name}o", or "%{Set-Cookie}o".

Simple example for this existing access log configuration:

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

Add "%{Set-Cookie}o" to the format string on the LogFormat directive, resulting in

LogFormat "%h %l %u %t \"%r\" %>s %b %{Set-Cookie}o" common
CustomLog logs/access_log common

(There may be a number of different LogFormat directives... the one of interest is the one whose format name (e.g., "common") is actually referenced on your CustomLog directive.)

Do I have to start IHS as root?

On our non-Win32 platforms, IHS 1.3.x or 2.0.x must be started as root in order to bind to a low port. That is a hard requirement with no work-around on those platforms we support. A "low port" is a port below 1024. The normal web server ports (80 and 443) are low ports.

One work-around used by some Apache users is to utilize a firewall to redirect requests to port 80 to a high port. Then Apache (or IHS) wouldn't have to start as root in order to bind the port, since it won't bind to a low port.

what about log files over 2GB?

IHS 2.0.42.x and later

Windows

IHS >= 2 on Windows can write to log files > 2GB.

Unix and Linux

This is supported, except for rotatelogs, starting with cumulative i-fix PK01070, and with IHS 6.0.0.2.

IHS 1.3.x

Unix and Linux

This will not be supported.

I don't want anybody to know what server I'm running. What can I do?

You can't prevent the product name from being sent to clients in the Server header field, but you can minimize it to

Server: IBM_HTTP_SERVER
by coding
ServerTokens Prod
in the web server configuration file.

See also the ServerSignature directive for controlling whether information about the server is included in certain error messages.

Even without the standard Server header field in the response:

IHS 2.0.42.x prior to PQ85834 had a defect which allowed CGIs and plug-ins to override the value of the Server header field.

How to start IHS automatically at boot time on AIX?

Here are AIX inittab entries to start IHS 1.3 or IHS 2.0:

: ihshttpd:2:wait:/usr/HTTPServer/bin/httpd > /dev/console 2>&1     
ihshttpd:2:wait:/usr/IBMIHS/bin/apachectl start > /dev/console 2>&1 

The first entry is commented out (leading ":") and starts IHS 1.3. The second entry is active and starts IHS 2. For either 1.3 or 2.0, replace the path to httpd or apachectl with the chosen installation directory. The "apachectl start" command is a valid way to start IHS 1.3 or IHS 2.0. The "httpd" command is only valid for IHS 1.3.

How to save mod_status page at intervals?

When customers can't get to mod_status page from a browser, or when there is some load balancer in front that makes it difficult to get mod_status from a particular server, or when they want to have mod_status pages saved automatically, they can run something like this script on the web server machine. It requires that perl and wget be installed. Perl usually comes with the operating system, and wget is an open source program to save a web page in a file.

grabstatus.pl:

#!/usr/bin/perl -w

use strict;

my $STATUS_URL = "http://127.0.0.1/server-status/";
my $SLEEP_INTERVAL = 60; # seconds

while (1) {
  my $timestamp = time();

  system("wget -O serverstatus.$timestamp $STATUS_URL");

  sleep($SLEEP_INTERVAL);
}

If all you want is to know how many threads are busy and in what state, see mod_mpmstats.

How can I disable caching in Internet Explorer?

Use mod_headers with the following configuration:

  Header set Pragma "no-cache"
  Header set Cache-Control "no-cache"
  Header set Expires "-1"

How can I disable the HTTP TRACE method?

Refer to this document.

What is a substitute for mod_ssl's SSLRequireSSL directive?

The SSLRequireSSL directive is not supported with any level of IHS. IHS uses a different SSL implementation than available for Apache 1.3 or Apache 2.0.

Instead of using the SSLRequireSSL directive to specify that certain files or directories can only be served over SSL, a customer can achieve the same result in different manner, by denying access to the file or directory in the non-SSL configuration. In following example, files under URI /onlyssl can only be served over SSL:

...                                                                     
# /onlyssl can't be served by default
<Location /onlyssl>                                                     
 Order Allow,Deny                                                       
 Deny from all                                                          
</Location>                                                             
...                                                                     
<VirtualHost *:443>                                                     
SSLEnable                                                               
...                                                                     
# put this config for /onlyssl inside all SSL-enabled                   
# VirtualHost containers                                                
<Location /onlyssl>                                                     
  Order Allow,Deny                                                      
  Allow from all                                                        
</Location>                                                             
</VirtualHost> 
...

How can I see which cipher specification was negotiated for a specific request?

  1. Change the LogFormat directive to include the cipher specification as part of the information logged for each request. The format string %{HTTPS_CIPHER}e will log the name of the cipher (e.g, TLS_RSA_WITH_AES_256_CBC_SHA). Ensure that the LogFormat directive which is changed is for the format used on the CustomLog directive.

    Example:

    LogFormat "%h %l %u %t \"%r\" %>s %b %{HTTPS_CIPHER}e" common 
    CustomLog logs/access_log common 
    
  2. Look in the access log to find the cipher used. The position of the cipher will depend on where the %{HTTPS_CIPHER}e format string was placed in the LogFormat directive. Using the example LogFormat directive above, here are example access_log entries:
    9.48.108.152 - - [17/Feb/2005:15:37:39 -0500] "GET / HTTP/1.1" 200 1507 SSL_RSA_WITH_RC4_128_SHA 
    9.48.108.152 - - [17/Feb/2005:15:37:40 -0500] "GET /httpTech.view1.gif HTTP/1.1" 200 1814 SSL_RSA_WITH_RC4_128_SHA
    9.48.108.152 - - [17/Feb/2005:15:37:40 -0500] "GET /httpTech.masthead.gif HTTP/1.1" 200 11844 SSL_RSA_WITH_RC4_128_SHA 
    9.48.108.152 - - [17/Feb/2005:15:37:41 -0500] "GET /httpTech.visit1.gif HTTP/1.1" 200 1457 SSL_RSA_WITH_RC4_128_SHA 
    

    For non-secure requests, "-" will be logged for the cipher specification.

The key size can be logged with the %{HTTPS_KEYSIZE}e format string. See the section on SSL environment variables in the IBM HTTP Server InfoCenter for information about other SSL environment variables which can be logged. See the documentation for the LogFormat and CustomLog directives for more information about format strings in general.

A manual way to check this is to use Ethereal on the client box and start a packet trace capture. Then load the web page. Then stop the capture in Ethereal and look for the Server "Hello" response. This will appear in the packet window like this:

  1.750088  server-ip-address client-ip-address TLS   Server Hello, Certificate, [Unreassembled Packet]

Select that packet, then look for the "Handshake Protocol" information in the next window:

    Handshake Protocol: Server Hello
        Handshake Type: Server Hello (2)
        Length: 70
        Version: TLS 1.0 (0x0301)
        Random.gmt_unix_time: Apr  8, 2005 14:15:33.00000000
        Random.bytes
        Session ID Length: 32
        Session ID (32 bytes)
        Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
        Compression Method: null (0)

Check the display of the cipher suite.

How can I downgrade response to HTTP/1.0 for certain requests?

<Location /some/url>
SetEnv downgrade-1.0 1                                                  
</Location>

Does rotatelogs rotate log files if no requests are received?

No, the rotate operation will not occur until IHS logs another request. If your configuration specifies that rotatelogs performs the rotation operation after 86400 seconds, and if IHS receives no requests after 86400 seconds have elapsed, the new log file will not yet be created. Then, when rotatelogs receives its next request to log, it will create the new log file and close the old one.

What about the LockFile directive? I can't see the lock file in the filesystem.

Short answer: This is working as designed; the lock file doesn't show up in directory listing except for a brief moment during IHS initialization.

Long answer: When IHS initializes an fcntl accept mutex during startup, it opens/creates the lock file, retains the file descriptor, but "unlinks" the lock file so that it is removed from the system just in case IHS exits abnormally and is unable to run its normal cleanup code. This procedure is a standard technique to avoid leaving dangling files after process termination, but it results in the file being invisible to the ls command. This means that other applications can't mess with the file, accidentally or not, since they can never open the same lock file used by IHS.

If you really want to see the lock file working, you can pick an IHS child process and run truss against it. ("truss -p PID") At the end of processing one client, a call like this will appear:

kfcntl(19, F_SETLKW, 0x2000AEE0) (sleeping...)

So file descriptor 19 is the lock file. (This actual number will almost certainly be different in your environment.) lsof when run against an httpd process ("lsof -p PID") would display that file descriptor as follows:

httpd   23104 root  19w  VREG    10,8   0 2261678 /home (/dev/hd1)
The size (7th column) should be 0 and the filesystem (two last columns) should match the filesystem used by your LockFile directive.

What are these requests for file favicon.ico in my logs?

A customer sees something like this in his access log:

127.0.0.1 - - [08/Mar/2005:12:51:08 -0500] "GET /favicon.ico HTTP/1.1" 404 304

Requests for favicon.ico are unavoidable. Internet Explorer and some other browsers will blindly request favicon.ico in case the web site has that file. You may have noticed that on some web sites, there is a cute icon in the URL box on your web browser; favicon.ico from that web site is the cute icon. Most web sides don't have that file, so there will be a 404 in the web site's access log and the browser will use the default icon.

The customer is not in control of whether or not the browser issues that request. They can have their site designer provide a favicon.ico file or they can ignore the entries in the access log. We do not recommend that they filter out the entries from the access log, because if there is ever a question of what requests are hitting the server, then the access log wouldn't be able to answer that question.

Why do I get 403 Forbidden trying to view server-status reports?

There are two common problems:

  1. The server status page is protected, and the client doesn't meet the authorization criteria. For example, there may be an allow from directive for <Location /server-status> which is not working.
  2. The configured DocumentRoot directory isn't readable by the web server user id (e.g., nobody). If this is the cause, the error log will have a message like the following:
    [Sat Mar 12 06:36:21 2005] [error] [client 127.0.0.1] (13)Permission denied: access to /server-status/ denied
    

Linux and Unix: How do I keep IHS from terminating child processes prior to web server shutdown?

Occasionally, problems with IHS or third-party modules can be attributed to issues which occur when IHS child processes terminate. In this case, it is helpful to disable child process termination until the problem can be fully resolved.

IHS 2.0 and above

Set MaxRequestsPerChild to 0 and set MaxSpareThreads to the same value as MaxClients.

IHS 1.3

Set MaxRequestsPerChild to 0 and set MaxSpareServers to the same value as MaxClients.

How do you gracefully shut down IHS?

There is no mechanism to shut down the web server yet allow active requests to gracefully finish. Active requests must finish within about 7 seconds, or they may be forcefully terminated when the child process is killed.

mod_rewrite: how to redirect all non-SSL requests to SSL?

Here is an example where all requests received on port 80 are redirected to the SSL port. Replace www.example.com with the hostname of your server. The new VirtualHost container will automatically apply to any requests received on the specifed port (80), and mod_rewrite will always redirect these requests to the https (SSL) equivalent.

<VirtualHost *:80>
RewriteEngine on
RewriteRule ^/(.*) https://www.example.com/$1 [R,L]
</VirtualHost>

mod_rewrite: a character in my new URL is being escaped as %nn - how do I avoid that?

Example: The following RewriteRule is supposed to redirect requests for /datasheets to http://www.example.com/CatalogView?view=01&content=02#readme, but the # is getting translated to %23 in the response to the browser.

RewriteRule /datasheets http://www.example.com/CatalogView?view=01&content=02#readme

By default, mod_rewrite will perform URI escaping on special characters such as '#', such that the rewritten URL contains the percent sign followed by the numeric code for the character. The escaping behavior can be overridden with the noescape processing flag. Here is the new RewriteRule which avoids the escaping:

RewriteRule /datasheets http://www.example.com/CatalogView?view=01&content=02#readme [R,NE]

Consult the mod_rewrite documentation for more information.

Note: If there is a question about what is being sent to the browser, the RewriteLog and RewriteLogLevel directives can be used to turn on logging in mod_rewrite, or the Location header field can be logged in the access log by adding %{Location}o to the access log format.

How to skip writing access log records for images?

Set a variable called image-request when the request is for certain filenames. Then, update the CustomLog directive to indicate that requests should not be logged when the image-request variable is set.

SetEnvIf Request_URI \.gif$ image-request
SetEnvIf Request_URI \.jpg$ image-request
# add another SetEnvIf directive for other file extensions to be skipped
CustomLog logs/access_log common env=!image-request

The mod_log_config documentation has an example showing how to put image requests in one access log and non-image requests in another access log.

My request failed with status nnn. How do I find out why?

Generally speaking, requests can fail in one of the following functional areas:

  1. IBM HTTP Server core features (e.g., access was denied, file was not found, etc.)
  2. WebSphere plug-in (e.g., communication error occurred trying to contact the application server)
  3. WebSphere Application Server (e.g., customer application returned a failure due to database problem)
  4. third-party module loaded into IBM HTTP Server failed the request (e.g., couldn't contact LDAP server)

Finding the root cause requires finding which functional area failed the request. This can usually be determined by checking the log files maintained by the various components.

  1. Check the IBM HTTP Server access log to find the entry for the failing request. Example:
    127.0.0.1 - - [08/Apr/2005:06:40:08 -0400] "GET /cgi-bin/test-cgi" 500 658 -
    
  2. Check the IBM HTTP Server error log for messages at the same time. Example:
    [Fri Apr 08 06:40:08 2005] [error] (13)Permission denied: exec of 'test-cgi' failed
    [Fri Apr 08 06:40:08 2005] [error] [client 127.0.0.1] Premature end of script headers: test-cgi
    

    In this case, an IBM HTTP Server feature failed, and the error log contains more information.

    If no entries were written to the error log at the time of the failure, the problem must have occurred in an area other than IBM HTTP Server. Proceed with the following checks.

  3. Check the WebSphere plug-in trace file for messages at the same time. If the WebSphere plug-in encountered a processing error (e.g., could not connect to the application server), it will be reported to the trace file.

    If no entries were written to the plug-in trace file, the problem must have occurred in a different area. Proceed with the following checks.

  4. Check WebSphere logs for error messages at the same time. Alternately, turn on detailed WebSphere plug-in trace and reproduce the problem. With a detailed plug-in trace, the HTTP status code returned by WebSphere will be traced, and you can see if WebSphere is the source of the failure (e.g., the functional area which returned status code 500).

    If WebSphere didn't process the request, or WebSphere returned a good response code for the request (e.g., 200 or 302), the problem must have occurred in a different area. Proceed with the following checks.

  5. Check logs of third-party modules (modules from non-IBM source loaded into IBM HTTP Server) for error messages reported at the same time. Contact third-party module vendor for explanation.
  6. If all else fails, and the platform is Solaris:

    It is likely that truss can be used to show which module is failing the request. If at all practical, re-configure IHS temporarily to use a single child process for processing client requests. Here is an example with IBM HTTP Server 2.0 or above:

    <IfModule worker.c>
    ThreadLimit         256
    ServerLimit         1
    StartServers         1
    MaxClients         256
    MinSpareThreads     1
    MaxSpareThreads     256
    ThreadsPerChild     256
    MaxRequestsPerChild  0
    </IfModule>
    

    Then start IHS as normal, and find the process id of the two IHS child processes via ps.

    # cat /opt/IBMIHS/logs/httpd.pid
    99999                <- example value
    # ps -ef | grep 99999
    webuser 10001   99999  .....
    webuser 10002   99999  .....
    root    99999   1      .....
    

    These two processes with 99999 for the parent are the two IHS child processes. One will be mod_cgid daemon and one will actually serve requests. We'll just trace both of them to avoid picking the wrong child process.

    # truss -o /tmp/tracefile -u :: -u a.out,\* -p 10001 10002
    (Replace 10001 and 10002 with the actual pids of the IHS child
    processes.)
    

    Next, reproduce the problem.

    Next, interupt the truss process (<Ctrl>C). The tracing via truss will slow down the web server significantly and will generate a large amount of output, so reproduce the problem and stop the tracing as quickly as possible.

    Here is the type of information we would expect to find. In this example, I have configured mod_access to return 403 (access denied) for a certain request:

    $ grep 403 /tmp/outfile
    11729/27@27:                      <- mod_access:check_dir_access() = 403
    11729/27@27:                    <- ap_run_access_checker() = 403
    11729/27@27:                    <- decl_die() = 403
    11729/27@27:                  <- ap_process_request_internal() = 403
    11729/27@27:                  <- ap_die() = 403
    

    The first place where 403 showed up (i.e., the module which set 403) was mod_access.

    For your situation, search for the bad status code (e.g., 500) in /tmp/outfile and see which module (mod_sm, mod_access, whatever) set the 500. Send in the trace file for us to analyze if it isn't clear which module set 500, or if an IBM-provided module set 500. If the status was set by a third-party module, contact the vendor for diagnosis.

At the present time (20050408), we anticipate that a fix pack for IBM HTTP Server 6.0.x and a cumulative e-fix for IBM HTTP Server 2.0.x available at the end of Q2 '05 will provide a mechanism for recording the point of failure in the access log.

Questions which apply to IBM HTTP Server 2.0 and above

AIX: Why am I unable to unmount filesystem containing files served by IHS (affects HACMP environments)?

IHS 2.0 on AIX normally serves files using the send_file() API. This results in the files being stored in the AIX Network Buffer Cache. This leaves the files open as long as they are in the cache, preventing the underlying filesystem from being cleanly unmounted.

To clear files from the cache and unmount the filesystem:

  • set the size of the network buffer cache to zero temporarily to clear the cache

    The old cache size can be displayed by no -o nbc_limit. The cache size can be set to zero by no -o nbc_limit=0.

  • unmount the filesystem

  • restore the previous cache size
    no -o nbc_limit=old_value
    

    An important IHS configuration directive which relates to this the EnableSendfile directive. By setting EnableSendfile Off in the IHS configuration file, IHS won't use the AIX send_file() API, and thus static files served by IHS won't possibly be added to the network buffer cache.

    In newer IHS sample configuration files (starting with PQ85834), send_file() is disabled by default to eliminate the possibility that customers may encounter occasional sendfile nuances unless they choose to actually use it.

    IHS itself is not aware of which objects are in the network buffer cache and can't remove such objects. Subject to the constraints of the network buffer cache (smallest/largest cacheable object, total size), objects (files) are sometimes added to the cache by the AIX kernel as a side-effect of IHS invoking the AIX send_file() API.

    An infrequently used IHS module for AIX is the AFPA cache module. It also interacts with the network buffer cache and should be disabled if the customer does not wish to empty the network buffer cache prior to unmounting a filesystem containing files which were cached.

    What operations does the %D log format measure?

    The %D custom log format calculates the time to serve the request, from the time that the web server reads the first line of the request from the client to the time the web server processes the %D format while logging the results of the request. If there is a subsequent request sent on the same TCP connection, the time measured by %D may not cover the end of the last buffer of the response.

    What about MPM selection and prefork vs. worker?

    IBM HTTP Server 2.0 and above uses the worker MPM on Unix and Linux systems, and it cannot be replaced. Any information about Apache that suggests recompiling the web server for a different MPM does not apply to IHS, as the MPM is pre-selected and IHS cannot be recompiled by customers.

    What about mod_dir, mod_rewrite, and the WebSphere plug-in?

    >We would like to know the priority of the following directives.         
    >- mod_dir(dir_module)                                                   
    >- mod_rewrite(rewrite_module)                                           
    >- WebSpherePlugin(ibm_app_server_http_module)   
    

    mod_dir only handles objects which can be served by IHS as static files, so it cannot be used to redirect requests to WebSphere. mod_dir has the lowest priority of these modules, and the priority cannot be changed. It will only try to handle a request if the request was for a directory and no other module has decided to serve the request.

    With IHS 2.0, mod_rewrite always takes precedence over the WebSphere plug-in and, with the proper configuration, mod_rewrite can first rewrite URLs and then the WebSphere plug-in can see the rewritten URL and decide whether or not to serve it.

    Example: Customer wants to use mod_rewrite to change URL /home to /servlet/home/, and customer has configured the WebSphere plug-in to handle /servlet/*.

    Here is a mod_rewrite directive to map /home to /servlet/home, and at the same time pass it through to the WebSphere plug-in to allow it to see the rewritten URL. The PT flag on the RewriteRule is what allows the WebSphere plug-in to process the rewritten URL.

    RewriteRule ^/home /servlet/home [PT]
    

    Note: In IHS 1.3, the actual order of the LoadModule or AddModule directives also makes a difference. The LoadModule or AddModule for mod_rewrite needs to come after the WebSphere plug-in is activated to allow mod_rewrite to rewrite URLs and then have the WebSphere plug-in process the rewritten URL. This is not the case with IHS 2.0, where mod_rewrite always takes precedence.

    Questions which apply to IBM HTTP Server 1.3.x

    Where is mod_perl to work with IHS 1.3 on AIX?

    mod_perl does not work with IHS 1.3 or normal Apache 1.3 on AIX. There is a build trick with Apache 1.3 to turn on run-time linking, which is required for proper mod_perl support. This involves building Apache 1.3 from scratch with special build flags to enable run-time linking.

    Since IHS can't be rebuilt by the customer and IBM can't change the build of IHS due to customer migration concerns, customers need to use real Apache 1.3 with mod_perl. Information about how to build Apache 1.3 to use with mod_perl on AIX can be found on the web.

    What are the recommendations for AcceptMutex with IHS 1.3 on AIX?

    The accept mutex is necessary in multiple child process configurations to prevent the thundering herd problem, where multiple child processes wake up to handle a single incoming connection. The accept mutex is used to ensure that only one child process wakes up when an incoming connection is ready to process.

    The accept mutex is always used when there is more than one listening socket. When there is a single listening socket, the accept mutex is used unless httpd -V (IHS 1.3) displays -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT.

    The default for IHS 1.3.19 through IHS 1.3.26 on AIX is AcceptMutex pthread. This has the following problems with IHS 1.3:

    1. Idle child cleanup often doesn't work, as there is an incompatibility between the interface to pthread mutexes and the design of Apache 1.3's idle child cleanup. There is no work-around other than to switch the mutex mechanism to something else.
    2. There have been problems with third-party modules crashing in their child exit hook, and the child exit hook can sometimes be run while the process holds the pthread mutex. When this type of crash occurs, the server can hang. If fixes for the third-party module are not available, the mutex mechanism should be changed to something else. (This second issue has been sidestepped with Apache/IHS >= 1.3.28, as we have changed the code to release the accept mutex before running the child exit hook, in case the third-party module crashes there.)

      We have never seen this problem with IBM-provided modules (for example, the modules provided with IHS such as mod_rewrite, and the WebSphere plug-in module). If you are loading only IBM-provided modules into IHS (LoadModule directives in httpd.conf), then this is not a concern.

      If you are using non-IBM modules, we cannot predict in advance whether or not you will encounter this type of problem with that module. That depends on whether the exact version of that module has such a defect which can occur in your environment.

    choosing the accept mutex mechanism on AIX

    AcceptMutex pthread

    This is the default mechanism for IHS 1.3.19 through IHS 1.3.26.x. This mechanism uses the pthread_mutex_lock() function in the AIX pthread library to serialize access to the listening socket between processes. The lock is in shared memory, which allows multiple httpd processes to use it. There is no underlying file associated with this type of mutex, so the LockFile directive is ignored.

    pros

    1. high performance
    2. no system tuning required

    cons

    1. mutex ownership not recovered if the mutex owner crashes
    2. with IHS 1.3, the pthread mutex mechanism can interfere with idle process cleanup
    AcceptMutex sysvsem

    This is a possible mechanism for IHS 1.3 (1.3.19.3 and above). This mechanism uses the semop() and semctl() functions in the AIX kernel to serialize access to the listening socket between processes. There is no underlying file associated with this type of mutex, so the LockFile directive is ignored. The semaphore is viewable with the AIX ipcs command.

    pros

    1. high performance
    2. no system tuning required (internal AIX limits are sufficiently high)

    cons

    1. A semaphore set will be lost if the parent process crashes. The semaphore set will have to be manually cleaned up by the administrator using the ipcrm command.
    AcceptMutex fcntl

    This is the default mechanism for IHS 1.3.12 and below and for IHS 1.3.28 and above. This uses the fcntl() kernel function to serialize access to the listening socket between processes. The httpd processes wait for exclusive access to a lock file, then they can safely access the listening socket(s). There is no real file I/O performed. Because the mutex is file-based, a lock file will be used. Normally, the lock file is stored in the logs directory under the IHS ServerRoot directory. The LockFile directive needs to be used in the following situations to override the default name of the lock file:

    1. IHS ServerRoot directory is on a network file system; use LockFile directive to place the lock file on a local directory
    2. multiple IHS instances share the same ServerRoot directory; use LockFile directive in each httpd.conf to specify different files (No operational problem would occur if the LockFile directive was missing; however, it could be confusing during problem diagnosis to see open files used by different IHS instances and see that they each are using lock files with the same name.)

    pros

    1. no system tuning required
    2. widely used with Apache/IHS 1.3 on AIX, with no known problems

    cons

    1. performance is slightly less than AcceptMutex pthread or AcceptMutex sysvsem; the actual difference is hard to measure with real world workloads

    What format of text file userid/password is supported by IHS 1.3 on Windows?

    The authentication module which handles flat files of userids and passwords is mod_auth (described in the IHS Infocenters or in the Apache 1.3 documentation). On Windows, mod_auth accepts flat text files of the form

    userid:password
    

    There are three allowable forms of the password:

    1. unencrypted (not recommended)
      Example:
      jeff:jeff
      
    2. MD5 hash, prefixed with the string "$apr1$"
      Example:
      jeff:$apr1$PN2.....$iPOw99RhtaeLLZ6OnXeGW/
      
    3. SHA1 hash, prefixed with the string "{SHA}"
      Example:
      jeff:{SHA}8+cx36KTx6gxGdiqz6QbXS14C+k=
      

    The traditional "crypt" format of the password is not supported by IHS 1.3 on Windows.