Bug 842653

Patch for BZ ticket [https://bugzilla.redhat.com/659066], which is already merged, makes WebAdmin/UserPortal applications unable to detect missing resources served through root.war application. In consequence, this might break application behavior.

Following steps illustrate the problem on example:

1. WebAdmin requests [http://enginehost:8080/docs/en-US/DocumentationPath.csv]
2. root.war application's FileServlet mapping applies (/docs/*), and FileServlet tries to read [/usr/share/ovirt-engine/docs/en-US/DocumentationPath.csv]
3. Assume the documentation package is not installed, so FileServlet cannot read the file, and returns 404 ("resource not found") response

(following steps were introduced as part of [https://bugzilla.redhat.com/659066] patch)

4. root.war application's web.xml file declares that 404 ("resource not found") responses will go through ErrorServlet (instead of using standard JBoss AS error handling)
5. ErrorSevlet will redirect the response to root.war application's context root ("/") and welcome page (index.html) will be served as the response
6. WebAdmin receives the response with HTTP status OK, assuming that DocumentationPath.csv exists (but it doesn't)
7. WebAdmin tries to parse HTML (welcome page) as CSV

From end-user perspective, handling 404 ("resource not found") requests by redirecting to welcome page is a nice to have feature.

However, from application perspective, this might break things, as the application has no way to know if the response actually represents the requested resource. There are many types of files requested through root.war application, including Spice-related files, documentation files, even some Python scripts.

My suggestions (possible solutions):

1. Instead of doing immediate redirect to welcome page, customize the error page so that it contains a link to welcome page. The error page will still be served with appropriate HTTP status code (e.g. 404).

[This solution lets users know that they requested a missing resource, and allows them to return to welcome page as well.]

2. When redirecting to welcome page from within the ErrorServlet, make sure that the welcome page is still served with appropriate HTTP status code (e.g. 404).