tomcat-dev mailing list archives

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

On Thu, 2 Jan 2003, Donald Ball wrote:

> Date: Thu, 02 Jan 2003 12:49:40 -0500
> From: Donald Ball <>
> Reply-To: Tomcat Developers List <>,
> To:,
> Subject: RE: error-page status codes broken, no response to bugzilla   report
> On 1/2/2003 at 9:23 AM Craig R. McClanahan wrote:
> >> 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.
> <snip/>
> I read and understand that you can map error-page handlers to locations
> which in fact respond with the original status codes. Nonetheless, it still
> seems to me that the behavior is incorrect wrt the servlet spec, not to
> mention http and common sense. Again, I quote:
> ---
> Hmm. Digging around in the 2.3 spec more deeply, I note the description of
> HttpServletResponse.sendError reads:
> "Sends an error response to the client using the specified status clearing
> the buffer. The server defaults to creating the response to look like an
> HTML-formatted server error page containing the specified message, setting
> the content type to "text/html", leaving cookies and other headers
> unmodified. If an error-page declaration has been made for the web
> application corresponding to the status code passed in, it will be served
> back in preference to the suggested msg parameter."
> The first sentence clearly states that the response sent to the client must
> use the specified status code, regardless of whether the content body is
> generated by the server automatically or is read from an error-page
> location.
> ---
> It still seems to me that the status code of the error-page should be the
> status code of the response. Not only is that the behavior implied by the
> spec, but it also prevents naive web developers from writing webapps that
> return pretty error response pages tagged with status 200. The default
> behavior should be to preserve the http conversation, not to censor it. You
> argue that I should do extra work to preserve the status code. I argue that
> (if one really wanted to for some arcane reason) one should do extra work
> to hide it.

The key issue is that declaring an <error-page> handler ***replaces*** the
standard container behavior; it doesn't ***augment*** it.

Consider, for example, a webapp that want to implement something like what
the "Redirect" configuration parameter does for Apache (so that old URLs
still work).  In today's world, you can write such a thing by mapping 404
errors to a servlet that redirects to the desired resource (which
ultimately returns a 200) for the URLs it knows about, and just returns
the original 404 for everything else.

With your proposed change, it would not be possible to implement this
functionality.  That would be bad.

> Regardless of what you/we decide here for tomcat, should this be brought to
> the servlet expert group for clarification in a forthcoming servlet spec?

You're certainly welcome to send them mail:

and it's timely, since Servlet 2.4 is in Proposed Final Draft state, and
still subject to correction if needed.  (And I'm going to make the above
argument if it's brought up for discussion -- to say nothing of the fact
that this would break backwards compatibility for loads of existing
applications ;-).

> - donald


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message