On 20 March 2013 18:22, sebb <seb...@gmail.com> wrote: > On 20 March 2013 14:42, Gary Gregory <garydgreg...@gmail.com> wrote: >> On Wed, Mar 20, 2013 at 10:25 AM, Mark Thomas <ma...@apache.org> 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. >>> >>> http://svn.apache.org/viewvc?view=revision&revision=r1458726 >>> >> >> 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.
There are also reports of other crashes at a different location. I've tested it, and that appears to be because it fails to handle non-ASCII characters (outside the range 0-127). It's supposed to ignore these. Fixing that bug would require pre-scanning the input to remove them. I think the method as currently implemented is broken and we should avoid using it. > 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! Now fixed in SVN. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
