0

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
                \
                 \
                  WASServer6.1: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
                       \
                        \
                         WASServer: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?

Improve this question

2 Answers 2

Reset to default
0

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).

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

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .