Summary: | Encoding mismatch in error condition | ||
---|---|---|---|
Product: | Tomcat 5 | Reporter: | Udo Walker <Udo.Walker> |
Component: | Catalina | Assignee: | Tomcat Developers Mailing List <dev> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | jfclere, peter.blstak, soltis, suzuki.yuichiro |
Priority: | P2 | ||
Version: | 5.5.9 | ||
Target Milestone: | --- | ||
Hardware: | Other | ||
OS: | other |
Description
Udo Walker
2005-10-13 14:44:56 UTC
I understand your use case and your concern. But we can't count on the encoding being set somewhere before, can we? Even detecting that we're in the error case as opposed to a normal reset is somewhat challenging. If you've got a patch you want us to consider, please attach it to this issue. In bug 36814 I first thought it is some other problem in Tomcat. Then I found out the problem described above. In bug 36814 I described a possible solution with a context parameter to set the default encoding of the container. The solution was denied :( . I don't know how to solve the encoding problem if nobody is able to configure the default encoding. You could still implement the default encoding as ISO-8859-1 but then if there is a context parameter set then use the encoding value described there. How about the following corrections? org.apache.catalina.connector.Response: --- public void reset(int status, String message) { reset(); setStatus(status, message); usingWriter = false; // add for user error page } --- This makes the user error page be able to set encoding again. Even if there is already a generated Writer object, I think it has not been referred any longer usually because the application(filter, servlet, etc.) is already over. org.apache.catalina.valves.ErrorReportValve: in protected void report(Request request, Response response, Throwable throwable) ... try { response.setContentType("text/html"); response.setCharacterEncoding("utf-8"); // add for default error page if(!"utf-8".equals(response.getCharacterEncoding())){ response.getCoyoteResponse().setCharacterEncoding("utf-8"); } } catch (Throwable t) { ... If the writer object is already generated, setCharacterEncoding will not work. So I think we must force set encoding direct to coyote response. I know the specification says setCharacterEncoding should effect only before getWriter, and says nothing about getWriter in reset method description. But we need a fix in multi byte character environment. -1 for the patch you suggest. It works for your case but won't work for many users that don't use UTF-8. I have started a thread on the dev list about this. The mailing list thread is here: http://marc.info/?l=tomcat-dev&m=117280911532391&w=2 |