On 02/02/2012 11:25, Konstantin Kolinko wrote:
> cc: dev
> 
> 2012/1/23 kitagawa <kitagawawo...@gmail.com>:
>>>
>>> While developing using ubuntu 11.04, tomcat 6.0.33 and java 1.5 I ran
>>> into a problem after setting the character encoding filter for
>>> requests.
>>> When posting a request, the value of any field with only a single
>>> character submitted is cleared.
>>>
>>> I also tested this issue with:
>>> tomcat 6.0.32 and java 1.5 (no problem)
>>> tomcat 6.0.35 and java 1.5 (same error occured)
>>> tomcat 6.0.33 and java 1.6 (no problem)
>>> tomcat 6.0.35 and java 1.6 (no problem)
>>>
>>>
>>> This can be repeated using the RequestParamExample that comes with tomcat.
>>>
>>> 1. uncomment the "Set Character Encoding" line in
>>> apache-tomcat-6.0.33\webapps\examples\WEB-INF\web.xml (lines 88 and
>>> 93)
>>> 2. start tomcat
>>> 3. go to http://localhost:8080/examples/servlets/servlet/RequestParamExample
>>> and enter a single character into the first or last name fields then
>>> post.
>>>
>>> The entered value does not show up. Instead, the value shows up blank.
>>>  If I enter two characters they appear correctly.
>>>
> 
>>
>> I researched it some more and found a bug in Java 1.5 in
>> java.nio.charset.Charset.decode() that might be the cause.
>> A ticket was submitted regarding a similar problem to sun in 2004
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6196991
>> (patched in Java 1.6)
>>
>> Tomcat 6.0.33 r1140904 the
>> /tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/buf/ByteChunk.java
>> class was changed to use java.nio.charset.Charset.decode().
>> This is probably why there was no problem before in version 6.0.32.
>>
> 
> FYI: The same issue reported against 5.5.35:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=52579
> 
> Thank you for your research. I think you are right. Though I am not
> sure how much this can be fixed in Tomcat now.
> 
> 1. r1140904 [1] in 6.0.33 is a fix for issue 51400.
> Reverting it will reintroduce the issue.
> 
> 2. The recent code that uses Charset in 5.5.35 and 6.0.35 is part of
> fix for CVE-2012-0022 [2]
> So a different implementation might be needed.
> 
> [1] http://svn.apache.org/viewvc?view=revision&revision=1140904
> [2] http://tomcat.apache.org/security.html
> 
> The good news are that it does not affect UTF-8, so using that
> encoding may be a workaround.

This only affects those using Java 5. It is resolved in the latest Java
6. Anyone using Java 5 will be in one of two positions:

a) unsupported therefore they should upgrade to the latest Java 6 where
this is fixed

b) supported by Oracle in which case they can raise a bug with Oracle.

Either way, I am leaning towards WONTFIX.

Mark

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

Reply via email to