Http response code 404 means that the server is able to communicate with the client, but the resource being requested by the client cannot be located on the server. Before we get into how this is done on WebSphere, let's look at how this is done on a stand alone web server.

Stand Alone Web Server

Let's say a client requests bogus.html from a stand alone web server. If the web server does not contain a file named bogus.html, the web server will respond with http status code 404 - not found.

By default, nearly all web servers are configured to display 404 in the browser.

Or, you can check for 404 in the web servers access log.

2018-09-26 01:38:02 10.1.2.3 www.example.com GET "/bogus.html" HTTP/1.1 404

Stand Alone WebSphere Application Server

Similar to a stand alone web server, a stand alone WebSphere application server will respond with http status code 404 if the resource being requested does not exist.

By default, WebSphere will display 404 in the browser.

Web Server + Plugin + WebSphere

Diagnosing http response 404 is more tricky when a web server is configured to proxy requests to WebSphere. Typically, this is done using IBMs IHS web server and IBMs web server plugin. 

For example, let's say www.example.com is a web server that fronts WebSphere. When a request is submitted to www.example.com, the web server will hand the request off to the web server plugin, and then the web server plugin will request the resource from WebSphere. If the web server and the web server plugin and WebSphere are properly configured, the requested resource will be sent to the client. In this example, index.jsp was requested, and was successfully sent to the client.

If 404 is being returned, you usually want to start with some simple checks.

• Ensure the web server is running
• Ensure nslookup can resolve the web server hostname to an IP address
• Ensure the web server access log records the 404, as a way to confirm the request is getting to the web server
• Ensure the WebSphere application server is running
• Ensure nslookup can resolve the application server hostname to an IP address
• Ensure the application in WebSphere is running
• Ensure the context root of the application in WebSphere is correct
• If possible, ensure you can request an HTML page directly from the web server
• Ensure 404 is not returned when requesting the app directly from the WebSphere application server

If no problems are found after doing the things listed above, there may be an issue with the web server plugin. The plugin is an XML file, named plugin-cfg.xml. The plugin is located on the web server, at ihs_home/Plugins<version>/conf/plugin-cfg.xml. Or, if the web server has been federated into a WebSphere deployment manager, in the deployment manager, navigate to Servers > Web servers > your web server > Plug in properties  > View.

The plugin-cfg.xml file will need to have the context root of the app being requested, which is /beta in this example. There should only be one listing for each unique context root. If there is more than one listing, the plugin-cfg.xml file is misconfigured.

<UriGroup Name="default_host_yourCluster_URIs">
  <Uri Name="/beta/*"/>
</UriGroup>

In this example, URI /beta maps to the UriGroup named default_host_yourCluster_URIs. There should be a routing tag that contains the UriGroup, and this will list the cluster that the app is in, as well as the virtual host being used. You will want to ensure that the application resides in the cluster. Typically, virtual host "default_host" is used.

<Route ServerCluster="yourCluster" UriGroup="default_host_yourCluster_URIs" VirtualHostGroup="default_host"/>

You can also ensure that the ports listed for the default_host are the ports that the web server and WebSphere application server are using for the app.

<VirtualHostGroup Name="default_host">
  <VirtualHost Name="*:80"/>
  <VirtualHost Name="*:443"/>
  <VirtualHost Name="*:9080"/>
  <VirtualHost Name="*:9081"/>
  <VirtualHost Name="*:9443"/>
  <VirtualHost Name="*:9444"/>
</VirtualHostGroup>