Provide feedback on the IBM HTTP Server forum on IBM developerWorks.
IBM Installation Manager is only used with the IBM HTTP Server bundled with WebSphere Application Server. IBM HTTP Server 8.5.5 included with z/OS Ported Tools installs uses SMPE just like V7R0 did.
To use modern TLS ciphers, ICSF must be configured. See "RACF CSFSERV Resource Requirements" in the z/OS Cryptographic Services System SSL Programming for more information (including CSFRNG access).
IBM HTTP Server 9.0 uses /dev/random which also requires ICSF to be configured and accessible to the IHS userid.
In z/OS 2.2 and later, IHS'es use of CSFRNG can generate many audit events
The default configuration translate static files from IBM1047 to ISO8859-1. You can add later rules to fine-tune or opt out of translation for specific resources. Any time CharsetSourceEnc and CharsetDefault have the same value, translation is disabled. The specific value is not important.
<Directory /var/www/app1/static/> CharsetSourceEnc UTF-8 CharsetDefault UTF-8 </Directory >
<FilesMatch \.ascii$> CharsetSourceEnc UTF-8 CharsetDefault UTF-8 # Technically this is processed before Location and LocationMatch, and will be overridden # by <lLocation />, which is why NoImplicitAdd is required. CharsetOptions NoImplicitAdd </FilesMatch>
<Directory /var/www/myapp/style/> <FilesMatch \.css$> CharsetSourceEnc UTF-8 CharsetDefault UTF-8 # Technically this is processed before Location and LocationMatch, and will be overridden # by, which is why NoImplicitAdd is required. CharsetOptions NoImplicitAdd </Directory>
IHS does the inverse translation on request bodies of POST and PUT requests as configured by
mod_charset_lite
. On individual locations, this can be suppressed.
<Location /app1/form> CharsetOptions NoTranslateRequestBodies </location>
Use the LocationMatch stanza to define the following options. This will translate an xml or xsl file coming from the files/xml folder.
# Note, be sure to places this after existing/default translation rules. # Ideally, append it to httpd.conf. <LocationMatch ^/~user1/xml/.*\.x[ms]l$> CharsetSourceEnc IBM-1047 CharsetDefault ISO8859-1 CharsetOptions TranslateAllMimeTypes </LocationMatch>
When file parsed by Server Side Includes (SSI) contains "#include file=" (but not virtual=), the default configuration will not translate the included file. This is due to the default translation being specified in a <Location> but directly including a file in this way does not associate it with any particular URL-path.
One simple workaround is to re-specify the default translation configuration in a <Files> configuration section or in a <Directory> section.
This is resolved in PI62663.
When multipart form uploads are processed by IHS (such as CGI or PHP, but not forwarded to WebSphere) there are special translation considerations. Multipart form uploads might mix text data, which needs to be translated, with binary file uploads which must not be translated
IHS cannot partially translate the request body.
CharsetOption
, then the body is passed verbatim to the application without translation. The application
will need to be able to interpret the ASCII-encoded text parts of the multipart upload, and the file bytes will
need to be used verbatim.
Note: PHP on z/OS appears to work with this method.
There are a handful of subtle reasons that SAFRunAs
might not apply to your request.
SAFRunAs
must be specified in some context your script is running in!
Action
directive to pass scripts to an interpreter, make sure
SAFRunAs
applies to the location of the interpreter rather than
the path to the scripts -- even though the initial request is for the script.
# /usr/local/my-app-1.0/ has executables that might be native binaries, or text files # that specify #!/usr/bin/perl, #!/usr/bin/php-cgi, #!/bin/sh, or any other interpeter. Alias /my-app/ /usr/local/my-app-1.0/ <Directory /usr/local/my-app-1.0/> Options +ExecCGI SetHandler cgi-script Authname "LOGON REQUIRED" AuthType Basic AuthBasicProvider saf Require valid-user SAFRunAs %%CLIENT%% </Directory>
The Action directive allows you to pass your scripts to a custom
interpreter instead of executing them directly. Because of the way requests
to your script are translated into requests for the interpreter, the
SAFRunAs
config has to be associated with the path to the
interpreter. You provide the interpreter, which is often a wrapper around
something like php-cgi with custom environment variables.
# Give the wrapper a URL ScriptAliasMatch /cgi-bin/my-php-wrapper.sh /usr/local/php/my-php-wrapper.sh # Make up a new virtual mimetype to map requests to the wrapper Action indirect-php-script /cgi-bin/my-php-wrapper.sh # The wrapper itself must act like a CGI <Location /cgi-bin/my-php-wrapper.sh> Options +ExecCGI SetHandler cgi-script # Since our application runs entirely beneath the wrapper, it's where # we must conigure things like SAFRunAs Authname "LOGON REQUIRED" AuthType Basic AuthBasicProvider saf Require valid-user SAFRunAs %%CLIENT%% # This is IHS 9.0 / Apache 2.4 syntax <IfModule authz_core_module> <RequireAll> Require valid-user # Prevent direct access to the wrapper Require env REDIRECT_STATUS </RequireAll> </IfModule> # This is IHS 8.5.5 / Apache 2.2 syntax: <IfModule !authz_core_module> Satisfy all Require valid-user Order allow,deny # Prevent direct access to the wrapper allow from env=REDIRECT_STATUS </IfModule> </Location> Alias /my-app/ /usr/local/my-app-1.0/ <Directory /usr/local/my-app-1.0/> # PHP files in this dir should be sent to our indirect-php-script action AddHandler indirect-php-script .php # Access control for non-script resources Authname "LOGON REQUIRED" AuthType Basic AuthBasicProvider saf Require valid-user SAFRunAs %%CLIENT%% <Directory>
The core of Apache will assign content types based on dataset names from the conf/mime.types file. If there are no matches,
mod_mvsds will try to infer if the file is XML or HTMl to set an appropriate content-type. The type can be overridden with
LocationMatch
and ForceType
.
IHS before 8.5.5.4 (PI21655) had problems serving binary files from MVS datasets.
Apache has a major release (1.3, 2.0, 2.2, 2.4) approximately very 6 years. Modules need to be re-compiled to be loaded under a subsequent release. Typically, a change in the minor version will require almost no source code changes. Fixpacks never change the ABI or change existing APIs.
The API is not comprehensively documented outside of the header files shipped in the include/ subdirectory. Some documentation specific to Apache 2.4 has been recently expanded: