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. 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? - donald -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>