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]>

Reply via email to