https://bz.apache.org/bugzilla/show_bug.cgi?id=64938
--- Comment #2 from Mark Thomas <ma...@apache.org> --- The behaviour of other Servlet containers is irrelevant. What matters is the Sevlet specification. You could argue that the ServletResponse.setCharacterEncoding Javadoc does not permit null to be passed as the character set. Neither does it define the failure mode if an invalid character encoding is specified. This is one of the many areas where the spec could be better defined. One workaround may be to define the default character encoding in web.xml with: <response-character-encoding>UTF-8</response-character-encoding> rather than via the filter. Although that won't help if some resources require UTF-8 to be set explicitly. Another possible workaround is ServletResponse.reset(). The interplay of setLocale(), setContentType() and setChjaracterEncoding() along with getWriter() and the web.xml default encoding (and probably at least one other bit I have forgotten) means that this might not be as simple as it first looks. I can see the use case for being able to use null here so I'm planning on looking at this later today with a view to implementing it. I'll also see if we can get the Javadoc clarified that null undoes any previous call (assuming getWriter() hasn't been called etc.) -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
