On 21 March 2013 09:39, Mark Thomas ma...@apache.org wrote:
On 21/03/2013 05:35, Konstantin Kolinko wrote:
Hi!
Recent Mark's commits in Tomcat 7, 8 replaced custom
implementations(*) of base64
with use of the following class from JAXB:
javax.xml.bind.DatatypeConverter
This affects base64 processing in our own classes and in our copy of
Commons FileUpload.
The original fileupload library in commons was not changed (I do not
see [1] change in [2] @1459121).
[1] http://svn.apache.org/r1458726
[2]
http://svn.apache.org/viewvc/commons/proper/fileupload/trunk/src/main/java/org/apache/commons/fileupload/util/mime/Base64Decoder.java?view=markup
First, it seems wrong, as this JAXB API was not designed as a general
purpose base64 codec.
I hereby -1 on this change, on the following ground:
OK. While I don't agree with you completely, I do agree that it would be
better to find an alternative solution. I suggest that we copy the
Base64 decoder/encoder from Commons Codec to a new o.a.tomcat.util.codec
package and update Tomcat 7 8 to use that (and point the deprecation
markers to this implementation) rather than DatatypeConverter.
Also, there are a couple of fairly basic bugs in the Java 6 method as
currently implemented.
It cannot handle non-ASCII input (codepoints above 127) - instead of
being ignored as non-Base64, they cause AIOOB Exceptions.
As does a trailing pad if it immediately follows a 4-char chunk ending
in a pad, for example:
Zm8== = AIOOBE: 1
whereas
Zm8=A = OK, ignores the trailing A
I have some other bits and bobs to look at first today but I start on
this shortly unless anyone raises an objection.
Mark
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
