The documentation required to diagnose problems with ErrorDocument handling includes
If this message is written to the IHS error log at the time of the failure, install the fix for APAR PK01215:
[warn] [client nnn.nnn.nnn.nnn] mod_was_ap20: /some/URL not found
If the IHS release is 1.3.x without PQ87084, and the form of the
ErrorDocument
directive is
ErrorDocument nnn http://www.example.com/urlpath/
then there is a known problem which can cause the browser not to display the error document. Update to a level of IHS with the fix.
These levels of IHS have the fix:
Release | Minimal level with the fix |
1.3.19.x | 1.3.19.6 with either PQ87084 or PQ90262 |
1.3.26.x | 1.3.26.2 with either PQ87084 or PQ90262 or PK05084 |
1.3.28.x | 1.3.28.1 |
IHS 2.0 and above is not affected by this problem.
If the browser which does not display the desired ErrorDocument text is Internet Explorer, it may be due to the Show friendly HTTP error messages setting in the Advanced Internet Options.
It is usually simple to identify when Internet Explorer is displaying its own message for an HTTP error instead of what the server sent. The bottom left-hand corner of the error page will show "Internet Explorer", as in the following example:
The Show friendly HTTP error messages setting can be disabled, but that requires client modifications. The usual solution for this is to increase the size of the error document. Try a 64K document. Contact Microsoft support for definitive information on how to avoid having Internet Explorer display friendly messages without updating the client settings.
ErrorDocument 413
processingNormally, there are two components in the web server which can detect the post size limit problem:
The administrator can specify the PostSizeLimit
parameter in plugin-cfg.xml. The plug-in can then detect that the
limit has been exceeded, and it will return a 413 HTTP status code to
IHS, which in turn will return it to the web client (browser).
The administrator can specify the LimitRequestBody
directive in httpd.conf, and IHS can then detect that the limit has
been exceeded, and it will return a 413 HTTP status code to the web
client (browser).
Either of these checks will prevent a WebSphere application from seeing the request when the body size is more than the specified number of bytes.
The HTTP protocol also allows the browser to detect the problem.
The optimal way to handle such limits is for the
browser to implement the optional Expect: 100-continue
handshake with the server so that the browser first tells the server
the size of the upload, then the server tells the browser whether or
not it is okay based on the size, then the browser either continues
with the upload or displays an error to the user.
Popular web browsers such as Internet Explorer do not implement the
Expect: 100-continue
handshake. Instead, they simply
start uploading the data, however large, and continue uploading until
done. It is only at the end of the upload that they may see a
413 response from IHS (probably sent long before).
During the time that the web browser is still uploading the request body, IBM HTTP Server may drop the connection (after having already sent an error response). If the browser sees that the connection is dropped during the upload, it often will not see the error message which was sent previously, so the user will not see any error message.
IBM HTTP Server will not read unlimited amounts of request body when it has already been identified as too big. That ties up web server resources for too long and could consititute a Denial of Service. Given that the web server may drop the connection before the entire request body has been read, and that the web browser will not process the error response if it finds out that the connection has been dropped before it finishes uploading, the error message from the web server may or may not be displayed, depending on:
IBM HTTP Server L3 support can provide a sample plug-in module for IBM HTTP Server 2.0 and above which will cause the web server to read the entire request body before the error is sent. That usually results in the web browser displaying the desired message. However, this is not recommended for general use since it can tie up web server resources for a long period of time (as long as it takes the client to upload an arbitrary amount of data).
Status code | Special concerns |
---|---|
400 | In most cases where the client request is invalid,
ErrorDocument processing is skipped, as it is not
considered safe to continue processing the request once it has been
determined to be in error. |
401 | If you use an ErrorDocument 401 directive then it must refer to a local document. Otherwise, the client will not receive 401 and therefore it will not prompt for credentials. |
ErrorDocument
directive
to see if that resolves the problemThere are several mechanisms for specifying the desired error text. Try each of them to see if the problem is resolved.
ErrorDocument 404 "The file you requested was not found.
This mechanism has the problem that it is inconvenient to specify a document large enough to override the Internet Explorer Show friendly HTTP error messages setting.
ErrorDocument 404 "<html><meta http-equiv="refresh" content="1;URL=javascript:top.location.replace(/404.html))))"><body></body></html>
(Replace "/404.html" with the desired local URL.)
Some customers have found that this is the easiest way to have the browser display the desired error document.
ErrorDocument 404 /404.html
(Replace "/404.html" with the desired local URL.)
ErrorDocument 404 http://www.example.com/404.html
(Replace "http://www.example.com/404.html" with the desired remote URL.)
With this mechanism, be aware that a 302 redirect response is sent to the browser, so 302 will be logged in the access log instead of 404.
LogLevel
to Debug
in httpd.conf.LogLevel
to Trace
in
plugin-cfg.xml.