Thanks a lot for the priceless effort on B64, Seb! what's the status ATM, do you think it can be included in a RC?
TIA, all the best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Mar 21, 2013 at 12:41 PM, sebb <seb...@gmail.com> wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
