tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject RE: error-page status codes broken, no response to bugzilla report
Date Thu, 02 Jan 2003 17:23:30 GMT


On Thu, 2 Jan 2003, Donald Ball wrote:

> Date: Thu, 02 Jan 2003 10:26:10 -0500
> From: Donald Ball <dball@rhoworld.com>
> Reply-To: Tomcat Developers List <tomcat-dev@jakarta.apache.org>,
>      dball@rhoworld.com
> To: tomcat-dev@jakarta.apache.org
> Subject: RE: error-page status codes broken, no response to bugzilla  report
>
> On 12/23/2002 at 9:40 AM Costin Manolache wrote:
>
> >It is on my todo list ( I also need this to work, at least for 500 ).
> >Do you have a patch ?
>
> I have attached an erstwhile patch to the bug in bugzilla. It assumes the
> content type of the error-page resource to be text/html and uses rd.include
> instead of rd.forward to get the content body. I have a feeling that
> someone more well-versed with catalina's internals could write a better
> patch that gets both the http status code _and_ the content type correct,
> but I am not that person.
>
> Nonetheless, I think the patched behavior is much more correct than the
> current behavior and should be applied to cvs.
>

(Sorry for being out of touch earlier -- holidays and busyness and such).

I do not agree with the assertion that the current behavior is broken.

The <location> that you declare inside an <error-page> element is a
context-relative URL of a web application resource that should handle this
error *instead of* the container's default handling (which would be to set
the status code and message per the HTTP spec's description).  As such, it
is totally up to your declared resource to decide what to do.

For example, you could easily define a resource URL that is mapped to a
servlet that called response.sendError() to set the ultimate error code,
plus did some other stuff.  But that is up to you to decide, not up to the
container.  The container's job is to send back whatever your application
told it to send.

If you point at a webapp resource that *itself* returns a 200 status
(which is the default behavior for static resources served by the
file-serving servlet, and which is what JSP pages will return unless you
do something different inside them), a 200 is what you should see in the
final response to the client.

If you want something different, map your error page handlers to a servlet
that does something different.

> - donald
>

Craig McClanahan



--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message