tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: svn commit: r783570 - /tomcat/current/tc4.1.x/STATUS.txt
Date Thu, 11 Jun 2009 21:52:24 GMT
Konstantin Kolinko wrote:
> Thank you for detailed explanation.
> My analysis is the following:
> hres.setLocale(locale);
> call ->  o.a.c.Response.setLocale() -> o.a.c.connector.ResponseBase.setLocale()
> In o.a.c.connector.ResponseBase.setLocale() it calls
> CharsetMapper.getCharset(locale)
> and updates the contentType header.
> The problem is with those locales for which CharsetMapper.getCharset(locale)
> returns null.  There is an error in ResponseBase.setLocale() that it will set
>  contentType = contentType + ";charset=null"
> in those cases. How about fixing that?
> My understanding is that it will solve the issue, and won't change the
> error page encoding for existing applications.
> We cannot fix CharsetMapper, because it can be overwritten, but we can
> fix those places where it is called.
> Here is the patch:

Yep, that would also fix the issue. However, that patch changes the
behaviour of setLocale(). Whilst it shouldn't cause a regression there
is a risk that it might for some applications.

The 'right' / 'proper' fix for TC4 would be to implement
STRICT_SERVLET_COMPLIANCE and in particular, the change to getWriter().
Again, there is the risk of regression with this approach.

TC6 and TC5 already use UTF-8 for Tomcat's default error page. The
proposed TC4 page brings TC4 into line with TC5 and TC6.

My personal preference is for the small as possible 'band-aid' approach
to minimise the regression risk.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message