Bug 842653 - Allow detecting missing resources served through root.war application
Allow detecting missing resources served through root.war application
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-setup (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Juan Hernández
Tomas Dosek
: 842118 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2012-07-24 07:40 EDT by vszocs
Modified: 2012-12-04 15:03 EST (History)
9 users (show)

See Also:
Fixed In Version: si12
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-12-04 15:03:13 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description vszocs 2012-07-24 07:40:28 EDT
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).
Comment 1 Itamar Heim 2012-07-24 08:12:26 EDT
*** Bug 842118 has been marked as a duplicate of this bug. ***
Comment 2 vszocs 2012-07-24 10:45:01 EDT
Juan submitted a patch for this issue: http://gerrit.ovirt.org/6573/

The proposed solution is to keep the current behavior, but have welcome page served with appropriate HTTP status code (e.g. 404) when requesting missing resources.

Custom error page that links to welcome page can be easily added later on if necessary.
Comment 3 vszocs 2012-07-24 10:50:26 EDT
The above mentioned patch has been verified and is ready to be merged upstream (waiting on acks).
Comment 6 vszocs 2012-07-24 12:12:11 EDT
Patch [http://gerrit.ovirt.org/6573] has been merged upstream.
Comment 7 Tomas Dosek 2012-07-31 06:22:15 EDT
Verified - si12 - All changes that Juan mentioned in comment #5 are working properly according to Juan's description.

Note You need to log in before you can comment on or make changes to this bug.