Provide feedback on the IBM HTTP Server forum on IBM developerWorks.
This document is quite long, but is optimized for search.
This module is not included with any products that bundle IHS, therefore no customer or product support from IBM is available for it. No testing of third-party Apache HTTP Server modules is performed by IBM.
The general IHS guidance on third-party code is available here.
IBM support currently has no reason to believe that the two are not interoperable, other than performance warnings about the version of PCRE used in IHS.
At the time of this writing (2013), commercial support for mod_security was available from vendor. See http://www.modsecurity.org/projects/commercial/support/
This module is not included with any products that bundle IHS, therefore no customer or product support from IBM is available for it. No testing of third-party Apache HTTP Server modules is performed by IBM.
The general IHS guidance on third-party code is available here.
mod_spy has dependencies on relatively new mod_ssl features that are not yet available in mod_ibm_ssl.
For this IBM HTTP Server release... | Check here... |
---|---|
8.5.5.x | IBM HTTP Server 8.5.5 system requirements |
8.0.0.x | IBM HTTP Server 8.0 system requirements |
7.0.0.x | IBM HTTP Server 7.0 system requirements |
6.1 | WebSphere Application Server V6.1 system requirements |
There are two issues of compatibility:
Refer to this documentation:
As an example, if you need to support versions 5.1, 6.0, and 6.1 of the application server, you should use IBM HTTP Server 6.1 and the WebSphere 6.1 plugin. (According to the web server plug-in policy, the 6.1 plugin is the only version which supports all three application server versions.
IBM HTTP Server release | corresponding Apache release that it was based on | corresponding WebSphere Application Server release |
---|---|---|
6.0 | 2.0.47 | 6.0 |
6.1 | 2.0.47 | 6.1 |
7.0 | 2.2.8 | 7.0 |
8.0 | 2.2.8 | 8.0 |
8.5 | 2.2.8 | 8.5 |
9.0 | 2.4.12 + most fixes through 2.4.20 | 9.0 |
Note: Fixes from later levels of Apache are also included. The Apache releases above should be referred to for the purposes of third-party module compatibility as well as determining the base level of Apache fixes included, before additional fixes were incorporated to resolve specific customer problems.
First, check the previous table which lists the level of Apache on which your level of IBM HTTP Server is based.
IBM HTTP Server release | How to check |
---|---|
6.0 and above | Look in install_root/readme/CHANGES_HTTPD for the Apache
CHANGES text. Apache CHANGES entries are copied there when a fix from
a later level of Apache is integrated.
If the Apache CHANGES entry is in CHANGES_HTTPD, then your level of IBM HTTP Server has the fix. |
1.3, 2.0 | Check the readme.txt associated with the last cumulative e-fix which was applied. Those have one-line extracts of the Apache CHANGES entries, so the text won't match exactly. |
Cumulative fix packages for these releases use an APAR number for
the fix level instead of a higher version number. Support
documentation often lists the first fix package which resolves a
defect; e.g., PK07831 or later.
The table below, which provides
the order of the fix packages, can be used to determine if the defect
is already corrected in your level of IBM HTTP Server. If a later fix
package has already been applied, the defect is already resolved.
APAR number | Date of release | Notes |
---|---|---|
PQ85834 | Q2 2004 | 2.0.42.x users must install this or PQ87339 in order to apply
later maintenance.
2.0.47 users should install the latest cumulative fix instead of this. |
PQ87339 | Q2 2004 | This is needed only for Solaris users with certain levels of GSKit installed. |
PQ90698 | Q3 2004 | |
PQ94086 | Q3 2004 | |
PQ94389 | Q4 2004 | |
PK01070 | Q1 2005 | |
PK07831 | Q3 2005 | |
PK13230 | Q4 2005 | |
PK25355 | Q2 2006 | |
PK29827 | August 21, 2006 | This is the final cumulative fix package for 2.0.42.2. |
PK53584 | October 3, 2007 | 2.0.47 only |
PK65782 | May 23, 2008 | 2.0.47 only |
When a defect needs to be resolved, always apply the current recommended update instead of the first fix package that contained the fix.
For IHS 7.0 and earlier, IBM HTTP Server is a 64-bit application on HP-UX/ia64 and Solaris/x64. IBM HTTP Server is a 32-bit* application on other platforms, regardless of which WebSphere Application Server Supplement CD it was installed from. Many platforms, including AIX, HP-UX, Solaris, and 64-bit Linux, provide support for both 32-bit and 64-bit applications, so a 32-bit IBM HTTP Server is able to function properly even though other applications on the system may be 64-bit.
IHS 8.0 adds the ability to choose 64-bit binaries on Linux (all architectures), AIX, and Solaris/SPARC.
IHS 9.0 removes 32-bit options on Linux, AIX, and Solaris. Windows remains 32-bit only, but with a 64-bit JDK and appears at the Installation Manager level as a 64-bit package as a compromise/quirk. In other words, IHS is 64-bit only in 9.0 and later except for Windows where it is 32-bit only.
There is never any requirement to use a 32-bit or 64-bit IHS based on using a 32-bit or 64-bit WebSphere.
In version 8 and later, both full installs and individual fixpacks are organized in a very different manner and this issue is N/A.
Prior to Version 8, when selecting an IHS fixpack to download, you must select the fixpack that matches the architecture of the supplement CD you installed from.
To determine which supplement CD was used for the initial install, consult <ihsroot>/uninstal/version.txt and look for the "Architecture" label. This is the architecture of the installer, not IHS itself and reflects the proper Supplement CD or fixpack architecture.
Architecture name in <ihsroot>/uninstal/version.txt where IHS is distributed as 32-bit code on 32-bit and 64-bit Supplement media:
Platform | 32-bit string in version.txt | 64-bit string in version.txt |
---|---|---|
Windows | ia32 | x86_64 |
Linux | ia32 | x86_64 |
z/Linux | s390 | s390_64 |
p/Linux | ppc32 | ppc64 |
AIX | ppc32 | ppc64 |
Solaris | sparc | sparc64 |
In Version 8 and later, the SDK is not separately maintained and is included in the IHS fixpack.
When selecting a WASSDK fixpack for IHS, you must select a fixpack that matches the architecture of the Java originally installed.
To determine which architecture of java was bundled with your level of IHS, run <ihsroot>/java/jre/bin/java -version
to determine if it is 32-bit or 64-bit. If the output of the command contains any of s390x, amd64, or ppc64
then the 64-bit WASSDK package should be used.
With IHS 7.0, the java architecture usually matches the IHS architecture (see apachectl -V|grep Architecture, z/Linux installed from 64-bit supplements is an exception).
With IHS 6.1, the java architecture usually matches the architecture of the installation source (64-bit supplements or 32-bit supplements ).
In IHS V7 and earlier, one ifix is created for each IHS installed architecture (apachectl -V|grep Architecture
) and
the OS operating system is not a factor.
For example, the only AIX ifix available is 7.0.0.19-WS-WASIHS-AixPPC32-IFPM46234.pak since IHS is always 32-bit in these releases on AIX.
In IHS V8 and later, ifixes may come in two forms:
A single ifix valid for all installations of IHS such as '8.0.0.0-WS-WASIHS-MultiOS-IFPM46234.zip'.
An ifix generated for a particular OS and architecture that can service any IHS installable on that OS and architecture. Where IHS includes both a 32-bit and 64-bit choice on a given operating system, the ifix will be named after the 32-bit architecture but contain an update for whichever architecture was chosen at install time.
For example, 8.0.0.0-WS-WASIHS-SolarisSparc-IFPM46234.zip contains updates to both 32-bit and 64-bit IHS on Solaris/SPARC, and 8.0.0.0-WS-WASIHS-LinuxX32-IFPM46234.zip contains fixes for both IA32 and X64 Linux.
Net: The architecture selected at IHS installation time is not a factor in selecting which fix to download, and there will never be an AIX, Solaris/SPARC, or Linux download that displays a 64-bit architecture in the filename.
There are several ways to perform the initial download/installation of IBM HTTP Server. Each requires IBM Installation Manager (IIM). IIM installs and updates IBM software from online and offline repositories.
This table summarizes which components of WebSphere Application Server are available from Product Media, Passport Advantage, and Web repositories. For complete repository details, see the IBM HTTP Server entries here: Online product repositories for WebSphere Application Server offerings
IHS, the WAS WebServer Plug-in, and WCT are available in this IIM repository:
The contents of any IM repository can be mirrored with the IBM Packaging Utility, a complementary tool to IBM Installation Manager.
Part numbers for offline media are listed here: http://www-01.ibm.com/support/docview.wss?uid=swg27048323#supp. This media should be available if your Passport Advantage ID is entitled to any product that bundles IBM HTTP Server. These downloads are cross platform and very large.
There is no separate ILAN or "trial" offering. The provided offerings can be used under both the included ILAN license, or under the terms of a product license which has listed IHS as a supporting program.
IHS, the WAS WebServer Plug-in, and WCT are available in this IIM repository:
The contents of any IM repository can be mirrored with the IBM Packaging Utility, a complementary tool to IBM Installation Manager.
Part numbers for offline media are listed here: http://www-01.ibm.com/support/docview.wss?uid=swg27038625. This media should be available if your Passport Advantage ID is entitled to any product that bundles IBM HTTP Server. These downloads are cross platform and very large.
On ppc64le, separate URL's must be used for IHS, the WAS Plugin, and PCT as listed in the knowledge center.
If you have physical media from a product that included IBM HTTP Server, you should have media named "WebSphere Application Server Supplements". This contains the base level of IBM HTTP Server. See the following section for fixpack downloads.
Once you have an installation, IHS fixpacks can be obtained and installed several ways. The latest fixpacks for IHS can be viewed here
The following list is presented in order of ease of use.
In IBM Installation Manager, the preferences menu has a checkbox to search the ibm.com service repositories. IHS fixpacks are published to this repository, and IBM Installation Manager will be able to discover and install them without any additional configuration.
Fixpacks for the "WebSphere Application Server Supplements" can be downloaded from Fix Central. They are large IIM offline reposotiroes that include IHS fixpacks for all operating system / architecture combinations. Example links to Fix Central can be seen in the 8.5.5.7 fixpack document visible here
Creating custom installation repositories with IBM Packaging Utility
IBM HTTP Server does not support the HTTP/2 or SPDY protocols. IBM DataPower, however, does.
At startup, the IHS parent process writes its own process ID to the file
identified by the PidFile
directive. This file is used by most other
apachectl
commands to identify whether IHS is already running (start),
or to identify the currently running IHS process to operate on it (stop, restart).
The file is removed when IHS is stopped via apachectl or any platform-service specific mechanism like Windows Services or the z/OS sample jobs, but not if the operating system is abruptly stopped or the individual IHS processes are directly killed.
If you attempt to start IHS and a PidFile
already exists, it is replaced if its contents
do not match any running process. If its contents do match a running process ID, regardless
of what that process is, it requires a manual recovery (removal of PidFile
by the admin)
to recover. The server does not try to determine what kind of process matches the process
ID, because this is not something easily/portably done from the native runtime. Wrappers around
the apachectl script, or modifications to it, could probe with ps
in environments
where stale PidFiles
are a problem.
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.
Does it start counting when IHS sent a response back to the client, or does the timeout period start when client ACKed the response?
It could be at either point, depending on the situation. IHS will start measuring the KeepAliveTimeout as soon as it successfully queues all of the previous HTTP response to the TCP layer. The operating system TCP layer sits between IHS and the network (client). IHS isn't aware of some network flows such as ACK flows, but it is affected by ACK flows.
IBM HTTP Server version | Platform | Can files larger than 2GB be served? |
---|---|---|
1.3.x | all platforms | No |
2.0.x | Windows | Yes |
2.0.x | AIX, Linux, HP-UX, Solaris | No |
6.0.x, 6.1.x | Windows, HP-UX/ia64, Solaris/x64, z/OS (only provided for 6.1.x) | Yes |
6.0.x, 6.1.x | AIX, Linux, HP-UX/PA-RISC, Solaris/SPARC | No |
7.0.x and later | All Platforms | yes |
Supporting files larger than 2GB is theoretically possible on other version/platform combinations, but it breaks binary compatibility with plug-in modules, so the change cannot be made. 64-bit versions of IBM HTTP Server support files larger than 2GB.
In IHS 7.0 and later, the directive AddServerHeader can suppress the default Server: HTTP response header.
In releases prior to 7.0, 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.
Setting MaxRequestsPerChild to zero prevents this occurence.
There is no impact to server operation due to processes exiting in this way. The most common cause of threads taking too long to complete is a large (or zero) ServerIOTimeout in the WAS WebServer Plug-in.
Setting MaxSpareThreads equal to MaxClients prevents this occurence.
There is no impact to server operation due to processes exiting in this way. The most common cause of threads taking too long to complete is a large (or zero) ServerIOTimeout in the WAS WebServer Plug-in.
Two useful diagnostics are available in this area.
ps
.
Normal processes have just more than ThreadsPerChild number of threads, while processes trying to exit
usually only have several remaining threads.
GatherHangDoc
collector in ihsdiag. The report file
generate will annotate each thread and process to tell you if it's exiting, and what the threads are busy doing.
Refer to this document.
<Location /some/url> SetEnv downgrade-1.0 1 </Location>
filename.html
when the browser requests filename?
The mod_negotiation MultiViews feature can automatically select a file with appropriate extension when the browser does not provide a file extension.
Configuration:
LoadModule negotiation_module modules/mod_negotiation.so ... <Directory /prefix-for-multiviews/> Options +MultiViews </Directory>
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.
There are two common problems:
allow
from
directive for <Location /server-status>
which is not working.
[Sat Mar 12 06:36:21 2005] [error] [client 127.0.0.1] (13)Permission denied: access to /server-status/ denied
Generally speaking, requests can fail in one of the following functional areas:
Finding the root cause requires finding which functional area failed the request.
These versions have a feature which allows the failing component to be logged:
Steps to find the failing component:
LoadModule status_module modules/mod_status.so
ExtendedStatus On
LogFormat "%h %l %u %t \"%r\" %>s %b %{RH}e" common
127.0.0.1 - - [23/Jan/2006:08:09:51 -0500] "GET /foo.html HTTP/1.1" 404 317 (core.c/404/handler) 127.0.0.1 - - [23/Jan/2006:08:10:45 -0500] "GET /testcount.jsp HTTP/1.1" 500 644 (mod_was_ap20_http.c/500/handler) 127.0.0.1 - - [23/Jan/2006:08:11:19 -0500] "GET /cgi-bin/printenv HTTP/1.1" 404 322 (mod_cgid.c/404/handler)
If the module name is... | This component failed to handle the request... |
---|---|
core.c | internal web server handling of static files |
mod_was_ap20_http.c | WebSphere plug-in |
mod_cgid.c | web server support for CGI scripts |
mod_sm.c | SiteMinder |
Check the log files of the failing component for more information.
This can usually be determined by checking the log files maintained by the various components.
127.0.0.1 - - [08/Apr/2005:06:40:08 -0400] "GET /cgi-bin/test-cgi" 500 658 -
[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.
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.
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.
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, interrupt 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.
Yes, IHS can satisfy limited byte range requests for static content but cannot do so for content delivered via the WebSphere Plugin (due to the particular way the response is forwarded by the WebSphere Plugin). An enterprise application is free to parse the Range hader and issue its own 206 response, and it is forwarded unchanged by IHS and the WAS Webserver Plug-in.
MaxClients
directive on Unix and Linux systems?IBM HTTP Server 2.0 and above is essentially limited by the amount of memory. You can configure up to 20,000 threads per child process, and configure up to 20,000 child processes, for an overall limit of 400,000,000. However, the address space of an individual child process may be exceeded with that many threads, and system memory may be exceeded with that many child processes.
ThreadLimit
directive on Windows systems?IBM HTTP Server 2.0 and above on Windows has a built-in limit of 15,000 threads, but practical limits around 2500 or 5000 on 64-bit and 32-bit operating systems, respectively..
A customer cannot recompile or relink IBM HTTP Server.
If instructions for a third-party module mention recompiling the
web server for integration of the third-party module, consult with the
provider of that third-party module to find out how to load it into
the web server dynamically (using the LoadModule
directive).
If the customer requires that they be able to recompile or relink the web server, we recommend using the Apache web server, for which a plug-in is provided by WebSphere. The Apache web server is not supported by IBM, but the customer will be able to use it with WebSphere Application Server using the WebSphere plug-in.
For example, why does the origin server receive "http://www.example.com//index.html" as the URL?
The ProxyPass and ProxyPassReverse directives should have trailing slashes for the path and url arguments.
Bad example:
ProxyPass /mirror/foo http://foo.com ProxyPassReverse /mirror/foo http://foo.com
Good example:
ProxyPass /mirror/foo/ http://foo.com/ ProxyPassReverse /mirror/foo/ http://foo.com/
Specify the authentication directives within a <Proxy > container. An example using file-based authentication follows:
LoadModule auth_module modules/mod_auth.so <Proxy *> AuthType Basic AuthName "Restricted Files" AuthUserFile /path-to-password-file require valid-user </Proxy>
The mod_proxy documentation contains a simpler example which allows access to the proxy based on the client IP address.
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>
WebSphere Application Server and Java EE support setting custom HTTP response headers from applications (including filters), but do not offer any configuration-only support for HTTP Strict Transport Security (HSTS) or other HTTP headers.
IBM HTTP Server (IHS) has basic support for HSTS via a configuration that uses generic HTTP response
manipulation by using the mod_headers
module.
Decide if you want the semantics specified by the Strict-Transport-Security
Decide how long you'd like browsers to cache this information
Decide how you'd like sub-domains to be treated.
Decide if this domain will consent to be listed in a preloaded HSTS list.
Enable the mod_headers
module in your IHS configurationf file by making sure the LoadModule
directove for mod_headers is un-commented.
Use the Header
directive in each SSL virtual host that requires a
HTTP Strict Transport Security policy
For the example below, do not copy and paste the directive verbatim without first understanding HTTP Strict Transport Security.
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
Configure your non-SSL virtual hosts to redirect to their SSL counterparts:
In WebSphere, applications access the client IP address using the HTTPServletRequest API
and no configuration is needed. If you still want to copy the client IP into a request
header, here is one basic recipe that replaces any incoming X-Forwarded-For
header
with the clients IP address.
SetEnvIf Remote_Addr (.*) client-ip=$1 RequestHeader set X-Forwarded-For %{client-ip}e
<VirtualHost *:80> RequestHeader set X-Forwarded-User %{my-remote-user}e env=my-remote-user # This makes mod_rewrite run late enough to see the result of authentication <Location /> RewriteEngine on # %{REMOTE_USER} below does not depend on an environment variable RewriteRule .* - [E=my-remote-user:%{REMOTE_USER}] </Location> </virtualhost>
The last argument of the Header
directive takes an environment
variable which, if unset, prevents the header from being added. You can use
this in conjunction with the SetEnvIf
directive to set headers on
basic conditions. However, only one envvar is accepted, and there is no support
for logical expressions. This makes it somewhat difficult to add headers only
if two conditions are met.
One specific way to bypass this limitation is to look for another directive
that covers one of your conditions. For example, if you don't want to cache
requests for a specific directory from a specific browser, you can use the
LocationMatch
directive in conjunction with
SetEnvIf
:
<LocationMatch /dont/cache/.*> BrowserMatch MSIE is_msie Header set Cache-Control "no-cache" env=is_msie </LocationMatch>
Another (more general) way is to use the RewriteRule
and
RewriteCond
directives. Be wary of using this trick in
conjunction with virtualhosts - they do not inherit the
RewriteRule
.
RewriteEngine on RewriteCond %{HTTP_USER_AGENT} MSIE RewriteCond %{REQUEST_URI} ^/dont/cache/ RewriteRule ^/ - [E=nocache:1] Header set Cache-Control "no-cache" env=nocache
If neither of the above two works for your situation, the most general and
most verbose way is to construct a logical "and" expression from
SetEnvIf
directives:
# We would use SetEnv here, but it always runs after SetEnvIf; # just use a catch-all SetEnvIf instead SetEnvIf Request_URI "^/" nocache_uri=0 nocache_browser=0 nocache=1 SetEnvIf Request_URI "^/dont/cache/" nocache_uri=1 SetEnvIf User-Agent MSIE nocache_browser=1 SetEnvIf nocache_uri "0" nocache=0 SetEnvIf nocache_browser "0" nocache=0 SetEnvIf nocache "1" set_nocache Header set Cache-Control "no-cache" env=set_nocache
mod_headers is provided and allows some limited request header modification. It can:
No other manipulation is provided.
A custom plug-in module would have to be used if a different type of manipulation is required within IBM HTTP Server, including removing individual cookies from a Cookie header field.
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.)
IBM HTTP Server 2.0.42.x and later on Windows can write to log files > 2GB.
This is supported, except for rotatelogs, with cumulative i-fix PK01070 or later for 2.0.42.2 and 2.0.47.1, and with IHS 6.0.0.2 and later.
IHS 7.0 and later adds large file support to rotatelogs on all platforms
This means that IHS 7.0 and later does not impose any file size limits beyond what is imposed by the operating system, file system, and any non-IHS configuration settings such as ulimit. Those limits apply to IHS as they do any other application.
IHS doesn't include any such tools, but there are numerous third-party solutions for log file analysis. Search for "Apache log file analyzer" using your favorite Internet search engine.
We are aware that some IHS customers are successfully using Webalizer, a freely-distributed application available from http://www.mrunix.net/webalizer/.
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 system. 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.
(all platforms)
This uses
rotatelogs
or a third-party replacement. IBM HTTP Server
sends log records to an external program, referred to as a piped
logger, which is responsible for switching to a new log file when
certain criteria are met.
Refer to the Piped Logs section of the documentation for more information. See also common questions about rotatelogs.
(Linux and Unix platforms only)
This method renames log files while the web server is running and still writing to the old files then restarts the web server to open files under the normal name again.
Refer to the Log Rotation section of the documentation for more information.
Other methods may be equally effective, but if you are having troubles with a different method or a script provided by a third party, please use the documented methods before contacting IBM support for help resolving the problem.
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.
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.
Add an indication of the selected vhost to your access log format, and then retry the testcase.
Configuration changes:
SetEnv vhostname MAIN
to the main scope of
httpd.conf.
SetEnv vhostname UNIQUE-NAME
to each
VirtualHost container. Make sure UNIQUE-NAME is unique for
each virtual host.
%{vhostname}e
) to the access log
format.
%A
) to the access log
format.
ServerName
associated with the
virtual host which served the request (%v
) to the access
log format.
Example log format with these changes made:
LogFormat "%h %l %u %t \"%r\" %>s %b %A %v %{vhostname}e" common
Example setting of vhostname:
... SetEnv vhostname MAIN ... <VirtualHost something> ... SetEnv vhostname vhost8443 </VirtualHost> <VirtualHost something> ... SetEnv vhostname vhost443 </VirtualHost>
Now restart the web server and try the request again. Check the access log for the destination IP address and the vhost name:
127.0.0.1 - - [26/Apr/2005:07:10:36 -0400] "GET /file.html HTTP/1.1" 200 1647 9.42.114.51 myhost.example.com MAIN | | | IP address connected to by client---+ | | ServerName for selected vhost-------------------------+ | label for selected vhost-------------------------------------------+
Check if the vhost name logged (e.g., "MAIN") is the expected one.
If an unexpected vhost name is logged, that would explain why your
vhost-specific configuration is not applied to the processing of the
request. The IP address and ServerName
value which were
logged can provide further hints.
%p LogFormat
logs the port number
specified in the ServerName
or VirtualHost
directive for the virtual host that handled the request.
To have a meaningful differentiation via %p
you should always a specify a
VirtualHost
for each listening port.
Alternatively, when the directive UseCanonicalName
is set to off, %p
will prefer the port number
provided by the client in the HTTP Host: header.
These formats show 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 or %T format string while logging the results of the request. This logging (and resolution of %D/%T) occurs after WebSphere Application Server has written the entire response to the WebSphere Plugin, and the entire* response has been queued to the TCP layer by IHS (*:see Special considerations below).
%D formats the time in microseconds and %T formats the time in seconds. (%D is not available with IBM HTTP Server 1.3.)
Special considerations:
The web browser connects to web server 1, which proxies the request to web server 2, which serves the request using any mechanism (WebSphere, CGI, static file, etc.).
IHS on Windows uses a system call to obtain two timestamps, one just after the request line is read and the second when the access log entry is made. Although the Operating System returns a value that has microsecond granularity, the timer is only updated once every OS timer tick, that is, 64 times per second. Thus if IHS processes a request in less than 15 milliseconds it is possible that 0 will be logged for the time taken to serve the request.
This answer has been moved here.
This answer has been moved here.
Cache-Control: max-age=0
when you request resources via IHS because an untrusted certificate is presented.
max-age=0
Cache-Control header,
mod_cache will refresh the cache entry. It is not safe to call htcacheclean
with a running server.
Yes, both ExpiresDefault
and ExpiresByType
can add
expiration data to requests served by the WAS Plugin. Generally, we expect the
generator of the content (the customer's application) to set these headers
intelligently, because IHS as a gateway is taking a wild guess as to how long
a response remains cacheable.
Note that if the application does set the Expires header, mod_expires will not override it.
Use mod_headers with the following configuration:
Header set Pragma "no-cache" Header set Cache-Control "no-cache" Header set Expires "-1"
If you don't want every resource on your webserver to be uncacheable, you have to determine which resources the rules should apply to and add them to a more specific configuration section:
Example if your URLs ending in ".pdf" or ".php" should not be cached:
<FilesMatch \.(pdf|php)$> Header set Pragma "no-cache" Header set Cache-Control "no-cache" Header set Expires "-1" <FilesMatch>
Example if your URLs ending in ".pdf" should not be cached:
<LocationMatch \.pdf$> Header set Pragma "no-cache" Header set Cache-Control "no-cache" Header set Expires "-1" <LocationMatch>
For more information about how configuration sections / containers work, see The IBM HTTP Server information center.
For more information about mod_headers, see the mod_headers documentation.
If you don't know where or not your mod_headers rules are working inside of IBM HTTP Server, you can log their values by adding the following stanza to the LogFormat
directive that is in use by your CustomLog
directives:
%{Pragma}o %{Expires}o %{Cache-Control}o
Example pre-existing LogFormat: LogFormat "%h %l %u %t \"%r\" %>s %b" common LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined After modification: LogFormat "%h %l %u %t \"%r\" %>s %b %{Pragma}o %{Expires}o %{Cache-Control}o" common LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %{Pragma}o %{Expires}o %{Cache-Control}o" combined
Other alternatives include wireshark, mod_net_trace, or the Firefox Live HTTP Headers plugin.
UPDATE: You can log a cache miss by using SetEnv CACHE_MISS 1
and adding %{CACHE_MISS}e
in your LogFormat
directive. Modules such as mod_env are skipped when a response is served from the cache,
so the CACHE_MISS environment variable can only be set when the cache is not used.
If you are logging the Request Handler you will see the request handler change from the content generator (mod_cgid, mod_proxy_http, mod_was_ap20_http, mod_core) to an empty value. Under some circumstances this will happen on the third, not the second, request for cacheable content.
Alternatively with LogLevel debug set, the following message is issued when mod_cache has served the request:
cache: serving /foo
Finally, if the "Age" header isn't being set by the content generator or some intermediate cache/proxy, the presence of the Age header in the response indicates that the file is being served from the cache. You can log the outgoing Age: header in the access log by adding %{Age}o to your LogFormat directive.
High ThreadsPerChild allows the cache to be duplicated across fewer child processes and increases cache hit percentage.
MaxRequestsPerChild 0 (default) prevents graceful child termination, which throws away anything in a child processes cache.
MaxSpareThreads = MaxClients prevents graceful child termination, which throws away anything in a child processes cache.
See IBM HTTP Server Performance Tuning for details on adjusting ThreadsPerChild.
See #BASICDL for full details on trial downloads.
In this release of IBM HTTP Server, the IHS Admin Server is not configured until the Plugin Configuration Tool (PCT) has been run.
The WebSphere Plugin, as well as the Plugin Configuration Tool (PCT) must be explicitly selected for installation.
apache.exe -k start
"just work"?At installation time, Windows services for IHS are created with a name matching the IM "package group name", which
users can override and is also incremented for multiple installs. Coupled with running multiple instances of IHS from the
same installation directory, this means the "right" service name must be specified when using apache.exe -k
.
When installed on a 64-bit OS, the IHS installer uses 64-bit builds (when available) by default. If more then one architecture is available, there will be sub-choices below IBM HTTP Server in the "Features" panel of IBM Installation Manager. If multiple components are being installed, the "Architecture Selection" twistie will not be visible until the "IBM HTTP Server" twistie is clicked.
The JDK bundled with IHS and the WAS Plug-in is used for installation, post-fixpack configuration actions, and some certificate management.
Performance-wise, as high as you want; the server will only allocate as much memory while reading the header as it needs to.
However, if you can estimate the largest header you're likely to receive, you might want to just set LimitRequestFieldSize somewhat larger than that, rather than to some really huge value. That will offer some protection in case a garbage request comes in that looks like it has a really long header, keeping the server from continuing to read and allocate memory and maybe running out.
For the Windows platform, this may also be known by other terms such as 'Integrated Windows Authentication' (IWA), 'Windows Integrated Authentication', 'Windows Authentication', or 'Windows NT Challenge/Response authentication'.
No support is provided for these authentication protocols in IBM HTTP Server. Customers requiring this functionality should configure the corresponding technologies in the application server (e.g. SPNEGO TAI).
By default, if IHS maps a request to a directory name rather than a filename (e.g. /var/htdocs/images) and there's not an index.html file in the directory, IHS will return an HTML page listing the files in that directory. You might wish to disable this as a security measure.
Directory listings are generated by the mod_autoindex module. To disable all directory listings, you can remove the Loadmodule line for mod_autoindex and any occurrences of configuration directives that mod_autoindex implements (see the mod_autoindex documentation).
If mod_autoindex is loaded, whether a directory listing will be generated for a particular request is configured using the Options directive.
To disable directory listings for a specific directory and its subdirectories, turn off the Indexes option in that directory:
<Directory /var/htdocs/images> Options -Indexes </Directory>You can disable all directory listings by default:
<Directory /> Options -Indexes </Directory>But note that a more specific <Directory> section can turn indexes back on:
<Directory /var/htdocs/images/foo> Options Indexes </Directory>so search your configuration files for "Indexes" to verify that directory listings aren't re-enabled anywhere that you don't want them.
A .htaccess file in a subdirectory can also turn on directory listings. You can prevent that by configuring AllowOverride at the server level and omitting the Options argument, e.g.:
AllowOverride AuthConfig FileInfo
Summary: Either remove mod_autoindex completely from the configuration, or use Options and AllowOverride to disable listings in specific directories.
Links:
This question covers distributed platforms only. On the z/OS
platform, the install_ihs
command creates a separate
directory for each instance without creating another copy of the
product.
These are the minimal requirements that allow multiple web server instances to run from the same installation directory.
A different main configuration file (normally httpd.conf) is needed for each instance. Common directives can be stored in common files and included from the different main configuration files.
A combination of listen port and listen IP address cannot be used
by more than one instance. This is primarily configured with the
Listen
directive, but interfaces and ports may also
show up in other directives (VirtualHost
, Redirect
...)
Anything normally stored in the
install_root/logs
directory cannot be shared
between instances. So each instance must have unique values for these
directives:
SSLCacheDisable
directive is not configured.
bin/apachectl
has been modified to specify a different
-d
flag, or bin/apachectl
is launched
with an explicit -d
flag.
-d
flag does not
contain the file bin/sidd
.
Service install/create
cd \install_dir bin\Apache.exe -f conf/this_instance.conf -k install -n IHS6-this_instance
Service start (pick one)
The functional requirements are the configuration differences which make different web server instances behave differently, and are in addition to the operational requirements above. You may wish to have different plug-in configuration files for the different instances (WebSpherePluginConfig), or serve different static files for the different instances (DocumentRoot). Different ports or IP addresses will be used for the different instances.
IBM HTTP Server readmes and supporting software lists typically specify that xlC.rte 6.0 or higher must be used on AIX V5. xlC.rte V7 is upwardly compatible and can also be used. The specific V7 xlC.rte that has been tested with IBM HTTP Server is xlC.rte 7.0.0.1.
The Apache 2.0 API allows modules to implement one or more hooks to perform initialization or request processing. Here are a few of the hooks which modules can implement:
Occasionally, there are requirements that one module's hook runs before another module's hook. The Apache 2.0 module API allows modules to indicate, for each request processing phase, whether the module should be called first or last, or before or after another specific module. The hook order is defined separately for each hook. For example, a module could indicate that its transaction logger has to run before the transaction logger of other modules, and that its validate-user-id hook must run before that of mod_auth.
When modules don't have specific requirements, or when modules declare when they should run relative to other modules, the LoadModule order is not important. In fact, the LoadModule order can almost always be ignored with IBM HTTP Server 2.0 or above.
When modules have specific requirements for the order in which they run, but they fail to use the proper API to declare the required order to the web server, the user may be able to work-around problems by reversing the LoadModule order. There is no clear rule for the specific order of the LoadModule directives for module A and module B in order to make module A's hooks run before those of module B's. On some platforms the LoadModule for module A must come first; on other platforms, the LoadModule for module B must come first. There is no guarantee that reversing the LoadModule directives is a permanent change. If the system qsort() implementation in libc changes with system software maintenance or other changes are made to the configuration file, the LoadModule directive might have to be reversed again.
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:
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
.
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.
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.
In other words, the prefork MPM cannot be used with IBM HTTP Server.
There are multiple causes for this symptom.
cannot open: pkgadd: ERROR: checkinstall script did not complete successfully
The IHS server root, or some parent of it, is not world-executable (searchable). Solaris runs a packages scripts as the "noaccess" user, and needs to be able to search all directories between the root of the filesystem and the IHS server root.
pkgadd: ERROR: checkinstall script did not complete successfully
Installation of failed (internal error)
If a third-party security product (such as eTrust) restricts what root can do, consult the vendor of the security product if the GSKit installation fails.
The stash files created by ldapstash can be transferred between systems using any binary-safe transfer method.
mod_proxy_balancer is not supported when IHS is licensed/entitled via WebSphere Application Server.
This module is distributed alongside IHS on some platforms for use by WebSphere Community Edition only. It is intentionally excluded from the list of supported Apache modules in the IHS 7.0/8.0/8.5 infocenter
Note that WebSphere Application Server customers are licensed to use IHS in support of their WebSphere Application Server and not for any other purpose. The WebSphere plugin provides the corresponding function for this purpose, and for other purposes customer should use a dedicated load balancer, caching proxy, or Apache HTTP Server.
Since CE is no longer marketed, releases of IHS after V8R5 are not expected to include this code in any form.
Refer to this document.
When using mod_ibm_ldap, here are detailed instructions. Note that IHS on z/OS does not support mod_ibm_ldap, and mod_ibm_ldap is deprecated on all platforms starting from IHS v7. In those environments, use the Apache standard mod_ldap, for which there is copious documentation available in books and on the Internet.
Authenticating to an LDAP server is done using an LDAP bind. In your ldap.prop file:
Reminder: all these values have to be determined by the web server and LDAP server administrators. We have no way of knowing what the correct values are for the customer's environment.
Example ldap.prop:
ldap.URL=ldap://ldapserverhostname:389/profiletype=user,cn=sdbm ldap.transport=TCP ldap.version=3 ldap.application.authType=Basic ldap.application.DN=racfid=adminuser,profiletype=user,cn=sdbm ldap.application.password.stashFile=/usr/HTTPServer/keys/ldap.sth ldap.user.authType=Basic ldap.user.name.filter=cn=%v1
Then in the httpd.conf file, you can use something like
<Directory /protected/files Options IncludesNOEXEC Indexes LdapConfigFile /usr/HTTPServer/conf/ldap.prop AuthName "XYZ Corp. Protected Files" AuthType Basic Require valid-user AllowOverride None </Directory>
Now when a client user provides a userid of USERID and password of PASSWORD, mod_ibm_ldap will do the equivalent of these two ldapsearch commands. First, it verifies that the user exists:
ldapsearch -x -h mvs1 -p 389 -P 3 -b "profiletype=user,cn=sdbm" -D "DN=racfid=adminuser,profiletype=user,cn=sdbm" -w "<password from stash file>" "cn=USERID"The filter "cn=USERID" is constructed using the value of ldap.user.name.filter, replacing %v1 with the first word entered by the user (typically just the userid).
If that succeeds (which requires both that the ldap.application.DN and password be acceptable, and that the filter returns a single user), then it tries to bind using the user's userid & password to see if the password is correct:
ldapsearch -x -m mvs1 -p 389 -P 3 -D "DN=<whatever DN was returned by the previous query>" -w "<password entered by user>" xxxx(Not bothering with the base DN, or showing xxxx here, because it never gets to a query, it just tries the bind.)
The configuration shown so far is sufficient if you only need to verify that the user is in the LDAP directory and has the right password. If you need to restrict access to only some of those users, more configuration is needed.
First, you can specify an LDAP filter that the user's directory entry must match. In httpd.conf in the same section where "Require valid-user" is configured, add a directive like:
LDAPRequire filter "(&(jobtitle=accountant)(location=newyork))"Then access will only be allowed if the user's entry has a jobtitle attribute with value "accountant" and a location attribute with value "newyork".
You might instead need to base authorization on whether the user belongs to an LDAP group. That is reasonably well documented here, so I won't repeat it.
There's another issue the customer might run into.
In our testing, we've found that when using the LDAP server on z/OS with the SDBM or RACF backend, not all filters are supported. Simple filters with a single condition, like cn=%v1, work fine, but compound filters with multiple conditions, such as ((cn=%v1)(objectclass=person)), are rejected with a server error such as "R000128 Filter is not supported (sdbm_search)". In the error log, IHS might show something like:
[error] mod_ibm_ldap: failed to search 'LDAP Realm' with filter '(&(cn=ACID)(objectclass=person))': (53) DSA is unwilling to perform [warn] mod_ibm_ldap: LDAP server indicates that password is expired or user id is locked.
The customer should use ldapsearch to verify that their filters work with their LDAP server before configuring them in IHS.
If the customer does run into unexpected problems and wants to get an idea of what LDAP is doing, they can add these two lines to IHS_install_dir/bin/envvars:
LDAP_DEBUG=65535 export LDAP_DEBUGThen all LDAP communication will be logged quite verbosely in the error log, including server errors like the "Filter is not supported" message mentioned above.
IBM makes no claims of support for the IBM HTTP Server service running in an MSCS environment. The IBM HTTP Server service is a 'generic' service that is unaware of MSCS, and no testing with this environment has taken place. However, Microsoft apparently claims that MSCS will support generic MSCS-unaware services (such as the IHS service) in a limited way.
Any customers attempting to run the IBM HTTP Server service within an MSCS environment should contact Microsoft if they experience problems.
We are aware of one instance of a customer attempting to run the generic IHS service in this environment.
In this case the customer had some problems which Microsoft identified as a known defect in the
customer's version of Windows 2008 Cluster Service. The MS Cluster Service was mistakenly taking the startup
parameter as the service name. Microsoft claims this has since been fixed in the Windows 2008 R2 version of the
code. We are unaware of what other versions may have the same issue.
Microsoft was able to provide a workaround solution that seemed to resolve this particular customer's problem.
This workaround solution was to clear out the startup parameters.
For this customer, the command to do this was similar to:
Cluster res "IBM HTTP Server 6.1" /priv startupparameters=""
Any direct support for the MSCS environment by IBM HTTP Server would be a new requirement.
Interim fixes do not need to be uninstalled prior to applying fixpack maintenance. The IBM Installation Manager will display a warning at the top of the window if it will uninstall any interim fixes. The warning that is displayed is shown in Figure 1.
![]() |
Figure 1. Warning when fixes will be removed during fixpack maintenance |
Example: Applying an interim fix for PI31516 on versions 8.5.5.2 - 8.5.5.5
There are two interim fixes for PI31516:
The fix for PI31516 also went into IHS fixpack 8.5.5.5.
Scenario | User Action |
---|---|
Installing the iFix on 8.5.5.2 and then upgrading to 8.5.5.3 | iFix was automatically reinstalled; no action needed |
Installing the iFix on 8.5.5.3 and then upgrading to 8.5.5.4 | iFix was uninstalled; iFix needs to be applied again |
Installing the iFix on 8.5.5.4 and then upgrading to 8.5.5.5 | iFix was uninstalled; no action needed since fix is available in 8.5.5.5 |