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: FASTER? ------- Additional Comments From [EMAIL PROTECTED] 2003-01-29 12:30 ------- I've just been bitten by this bug. Nice to see the patch is available, but I would like to call your attention to RFC2045: "The encoded output stream must be represented in lines of no more than 76 characters each. All line breaks or other characters not found in Table 1 must be ignored by decoding software. In base64 data, characters other than those in Table 1, line breaks, and other white space probably indicate a transmission error, about which a warning message or even a message rejection might be appropriate under some circumstances." So, it seems discardWhitespace() should either discard all non-base64 characters or throw an exception. As the patch stands, other invalid characters will still silently corrupt the data. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
