commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: [fileupload] towards 1.3 release - feedbacks required
Date Wed, 20 Mar 2013 18:22:19 GMT
On 20 March 2013 14:42, Gary Gregory <> wrote:
> On Wed, Mar 20, 2013 at 10:25 AM, Mark Thomas <> wrote:
>> On 20/03/2013 01:09, sebb wrote:
>> > I think QPD(ecode) is now OK; it handles lowercase hex and rejects
>> > invalid characters.
>> >
>> > Base64Decode handles valid input OK, and rejects some invalid input,
>> > but could perhaps do with tweaking to handle PAD characters better.
>> > At present it treats an embedded PAD as the end of input (as per
>> > Codec) but maybe it would be better to only allow 1 or 2 PADs at the
>> > end?
>> FYI
>> Tomcat opted to bypass these Base64 issues but the solution requires
>> Java 6 or later.
> Good one! I like the simplicity of that solution, I wonder if that will
> work for [fileupload].

The Java 6 method DatatypeConverter.parseBase64Binary(String)
generates a byte array, rather than writing to an OutputStream, but
that would be easy to fix.

Testing shows that it ignores trailing chars if they are not a multiple of 4.
Also it handles concatenated input, provided that the padding is in
the correct place (char 3 and/or 4).

It's not so hot on some invalid input - I managed to get

java.lang.ArrayIndexOutOfBoundsException: 5

when I tried experimenting with padding in different places.

If we do decide to use the method, we should probably catch AOOBE and
turn it into an IOException.

If we do not want to go with Java 6 and that method, we should
probably treat concatenated encodings the same way it does.
But of course we won't emulate the crash!

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

View raw message