We have a web security tool which the client runs and which tries to take advantage of known security issues. It basically bombards the web application with all kinds of URLs trying to access files or other programs. For example:

http://server:8080/ipp-portal/block/cgi-bin/perl.sh

Now, this of course does not work, but unfortunately the ICEfaces Blocking Servlet returns a HTTP 200 code in certain situations instead of correctly returning a HTTP error status.

The request we have for the ICEfaces support touches two scenarios:

1. When sending a bogus URL to the BlockingServlet while NO user session exists, the response to the client browser comes from the "SessionExpiredResponse" class und it contains a HTTP 200 code. We would like ICEfaces to return a HTTP error code instead. The two attached classes are patches of the original classes and show the desired behavior. We need to know from ICEfaces support if returning an error code causes any problems for other ICEfaces components and, if not, we would like receive patch from ICEfaces which inclides this fix.

2. After a user session has been established, the response from the server for a bogus URL alternates between HTTP 500 and HTTP 200. Using the same URL you first run into an exception on the server while executing the "lifecycle.render(facesContext)" method in class com.icesoft.faces.webapp.http.core.JsfLifecycleExecutor (Line 19 in ICEfaces 1.8.2). This exception is caught in the class com.icesoft.faces.context.View (Line 78) and logged as "Unknown View" which in the end results in a ServletException and a HTTP 500 error on the client ... all correct so far. Now, every other time you invoke the same URL, the mentioned invocation of "lifecycle.render(facesContext)" DOES NOT throw an exception and as a result the browser receives a response with HTTP 200 code and an empty page.

We need a solution that the response would reliably always return a HTTP 500 code.