We have a current setup like the following:

  • HTTPServer - IBM HTTPD Server v?
  • WASServer6.1 - WebSphere Application Server v6.1 (Running App "A")

The basic communication is as follows on the listed ports. [All port numbers listed are the listening ports.] The plugin-cfg.xml is appropriately configured, and this same topology has been operating in a Production environment for 6+ years.

HTTPServer:8080 --> WASServer6.1:9081

We now need to adapt in these new things, changing the topology somewhat:

  • IHSServer - IBM HTTPD Server v? (newer than above)
  • WASServer8.5 - WebSphere Application Server v8.5.5 (Running App "B")
  • AuthService - Stand-alone Java service (not running in app container)

    HTTPServer:8080 ---> AuthService:9090 ---> IHSServer:8081 ---> WASServer8.5:9081

HTTPServer has httpd.conf configured with ProxyPass directives that proxy certain requests to AuthService:9090. AuthService does some work, and then copies the headers of the request into a new [POST] request that is sent to IHSServer:8081, where the plugin-cfg.xml is mapped with the App B information to forward requests on to App B running on WASServer8.5. The ultimate goal is to take advantage of the plugin's state-awareness of the WAS JVMs. In our Production-level environment, there would be multiple JVMs to which IHS could forward requests.
NOTE: The AuthService is stateless, and so there is no need for any affinity to a particular JVM on WAS.

The problem is that this doesn't work for some reason. Requests sent through this path return with a HTTP 404 from IHSServer.

Troubleshooting with verbose logging for IHSServer has revealed that for some reason IHSServer is seeing the port number of the original forwarding proxy (HTTPServer:8080) and comparing it to the VirtualHostGroup virtualhosts listing in the plugin-cfg.xml (Why?). Finding no suitable match for port 8080, it gives up and spits out a 404.

If we replace things, as below, by first hitting some other Apache server listening on Port 80:

    SomeOtherHTTPServer:80 ---> AuthService:9090 ---> IHSServer:8081 ---> WASServer8.5:9081

...the request is accepted by IHSServer and things work properly. Similarly, if an appropriately-formed request payload is sent directly to AuthService:9090, the request is accepted and everything works.

We attempted to add <VirtualHost Name="*:8080"/> to the plugin-cfg.xml on IHSServer, but that doesn't seem to make a difference.

EDIT: We've taken some tcpdump captures at every node along this pathway, and it's clear that IHSServer immediately rejects requests with a 404 when they've come through the HTTPServer:8080. IHSServer doesn't even attempt to do anything with the request.

What other things could we do to troubleshoot/correct this? Why does the plugin on IHSServer care about the listening port of an upstream web server?


I didn't see "ProxyPreserveHost" in your post. Have you tried it?

It seems to me a likely cause for a 404 generated by the IHS server on port 8081 (due to no match in plugin-cfg.xml and handled as a static file) or by the AppServer itself (when it checks its own notion of host aliasts to determine a web app mapping).

  • At which point would that come into play? In my example above, which host would need that directive?
    – PattMauler
    Mar 21 '16 at 22:35
  • The one with proxypass
    – covener
    Mar 21 '16 at 22:39

You possibly need to also add the Virtual host alias VirtualHost Name="*:8080" in WASServer8.5 too. Then restart the WAS 8.5 server to take the change and this should work.

Generally, you need to configure the Virtual host(*:8080) in all levels from IHS conf to WAS plug-in to WAS VirtualHosts.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.