DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9931>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9931 Base64 decoder chokes on a whitespace ------- Additional Comments From [EMAIL PROTECTED] 2003-04-04 04:56 ------- the patches were applied to Jakarta Commons Sandbox Codec, so the most recent version is fixed with repsect to this bug. There was one problem with the patches supplied in that the function discardWhitespace did more than discard whitespace. It groomed the data of any invalid bytes. This made isArrayByteBase64 irrelevant because the logic was ensuring that the array supplied was valid base64 before passing it to isBase64. This bug was caught with the help of Clover, when trying to reach 100% coverage, I noticed that isArrayByteBase64 would never return false: http://jakarta.apache.org/commons/sandbox/codec/clover/index.html Anyway, the general idea was that it is valid to discard whitespace because some RFCs specifically call for introducing whitespace in the encoding process ( creating a chunked encodding ), but it didn't seem right to just throw out any non-base64 character willy nilly. decode throws an Exception if it encounters a byte that is clearly out of bounds.
