On Thu, 2 Jan 2003, Donald Ball wrote:
> Date: Thu, 02 Jan 2003 12:49:40 -0500 > From: Donald Ball <[EMAIL PROTECTED]> > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] > To: [EMAIL PROTECTED], [EMAIL PROTECTED] > 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: [EMAIL PROTECTED] 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 > Craig -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
