+

Search Tips   |   Advanced Search

Web server plug-in troubleshooting tips

If we are having problems using a web server plug-in, try these steps:

If these files don't reveal the cause of the problem, follow these additional steps.


Plug-in Problem Determination Steps

The plug-in provides very readable tracing which can be beneficial in helping to figure out the problem. By setting the LogLevel attribute in the config/plugin-cfg.xml file to Trace, we can follow the request processing to see what is going wrong.

(HPUX) Note: If we are using a Veritas File System with large file support enabled, file sizes up to two terabytes are allowed. In this case, if we set the LogLevel attribute in the plugin-cfg.xml file to LogLevel=Trace, then the http_plugin.log file might grow quickly and consume all available space on the file system. Therefore, we should set the value of the LogLevel attribute to ERROR or DEBUG to prevent high CPU utilization..

At a high level, complete these steps.

  1. The plug-in gets a request.
  2. The plug-in checks the routes defined in the plugin-cfg.xml file.
  3. It finds the server group.
  4. It finds the server.
  5. It picks the transport protocol, HTTP or HTTPS.
  6. It sends the request.
  7. It reads the response.
  8. It writes it back to the client.

We can see this very clearly by reading through the trace for a single request:

If none of these steps solves the problem:


Change in behavior when the web server uses an insecure transport

If we have secure and insecure transports defined, and a secure transport cannot be obtained due to a system failure, the web server plug-in uses an insecure transport. This is the default behavior.

This behavior has been changed in WAS v8.5.5. If a system failure occurs when attempting a secure connection, and there is an insecure transport, the web server plug-in does not use that transport. The administrator is made aware of the problem and can fix it using secure connections.

There are 3 options available to the administrator to address this problem:

  1. Correct the SSL issue so that the HTTPS transport is available (this is the recommended option).

  2. Remove the HTTPS transports if SSL is not used, and regenerate the plug-in.

  3. Set UseInsecure=true in the plugin-cfg.xml file to revert back to the previous default behavior.

To revert to the previous default behavior, we can enable it by setting a custom property on the administrative console. Select...

...and set UseInsecure to true.

(ZOS) If the HTTP server is not a managed server (it does not show up in the administrative console), we must manually edit the plugin-cfg.xml file. Read the Installing and configuring the plug-in for V5.3 HTTP Server for z/OS topic for more information.

To revert to the previous default behavior, we can enable it by setting a custom property on the administrative console. Select...

...and set UseInsecure to true.


  • How to fix GSK_ERROR_BAD_CERT (gsk rc=414) in plug-in log
  • Implement a web server plug-in