On 23 March 2013 14:27, Simone Tripodi <simonetrip...@apache.org> wrote: > 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?
Yes. > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
