Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4A317C98.50408@apache.org>
Date: Thu, 11 Jun 2009 22:52:24 +0100
From: Mark Thomas <markt@apache.org>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: svn commit: r783570 - /tomcat/current/tc4.1.x/STATUS.txt
References: <20090610233458.049422388882@eris.apache.org>
	 <4A312988.2040000@apache.org>
	 <427155180906111041j32807c5ap7868bfd210902e27@mail.gmail.com>
	 <4A315DD0.8070706@apache.org>
 <427155180906111432h449f2deg7505055d6d202f2@mail.gmail.com>
In-Reply-To: <427155180906111432h449f2deg7505055d6d202f2@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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:
> http://people.apache.org/~kkolinko/patches/2009-06-12_tc41_CharsetMapper.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.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org