DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8831>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8831 ErrorReportValve.java corrupts data in subtle way Summary: ErrorReportValve.java corrupts data in subtle way Product: Tomcat 4 Version: 4.0.1 Final Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] We have run into a few problems in ErrorValve.java which are causing very subtle data corruption in client applications. 1. First the minor problem: ErrorReportValve.report() has some inconsistent short-circuit logic. It will do nothing if: - response is already committed - response code is 1xx Continue - one of two specific 2xx response codes: 200, 204 - content not modified response code 304 If the response code is 2xx, then it is not an error, and ErrorReportValve should return. Why only 200 and 204? [In our case, we are doing WebDav, and a successful return code is 207 Multi-status. ErrorReportValve incorrectly interprets this as an error, which leads to the next problem...] 2. ErrorReportValve modifies headers, tries to write its own HTML error and fails, leaves modified headers with original body content. This one is really bad. If ErrorReportValve thinks there is an error, it does the following: - modifies the Content-type of the response to text/html - generates a big HTML message in a StringBuffer - then it tries to grab a Writer If the application has already obtained an OutputStream, then ErrorReportValve's attempt will fail with an exception, which is what happened in our case. To compound the problem, nothing is logged in the catch block of the exception! In our case, this causes our text/xml body to have a Content-type header of text/html, which causes all kinds of trouble - and there is no indication in any logs that there was a problem. Proposed solution: ------------------ It would be safest for ErrorReportValve to either grab the Writer first, before any changes are made to the HttpServletResponse. If that fails, then you could catch the IllegalStateException, and grab an OutputStream and wrap your own Writer around it. *Only after it has a known good Writer* should ErrorReportValve change the content-type of the response. That way, there is something visible to the application that is more clear that Catalina considers something to be wrong and the corruption to the response that ErrorReportValve has introduced is intentional, obvious, and thus rapidly fixable, rather than subtle and nearly undetectable. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
