You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rpc-dev@xml.apache.org by bu...@apache.org on 2002/09/28 01:43:56 UTC
DO NOT REPLY [Bug 9931] -
Base64 decoder chokes on a whitespace
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
dlr@finemaltcoding.com changed:
What |Removed |Added
----------------------------------------------------------------------------
URL| |http://cvs.apache.org/viewcv
| |s/xml-
| |rpc/src/test/org/apache/xmlr
| |pc/Base64Test.java?rev=1&con
| |tent-type=text/vnd.viewcvs-
| |markup
------- Additional Comments From dlr@finemaltcoding.com 2002-09-27 23:43 -------
Hmm. I just wrote a very simple test case for the Base64 implementation which
Jon nabbed from Tomcat (I found the attached one a bit too abstract to follow
easily). I was unable to reproduce the failure, even by appending whitespace to
the end of the line (you can try it out yourself with `ant test`):
<http://cvs.apache.org/viewcvs/xml-rpc/src/test/org/apache/xmlrpc/Base64Test.java?rev=1&content-type=text/vnd.viewcvs-markup>
Vjekoslav, can you tell me what the correct method of handling whitespace in
base64-encoded data is? The closest thing that I found to a RFC on that is
<http://www.zvon.org/tmRFC/RFC3156/Output/chapter3.html> -- it recommends
stripping trailing whitespace. Is this what Apache's implementation should be
doing? Or should it collapse all lines of base64-encoded data together, then
decode that?
Re: DO NOT REPLY [Bug 9931] - Base64 decoder chokes on a
whitespace
Posted by Dustin Sallings <du...@spy.net>.
Around 23:43 on Sep 27, 2002, bugzilla@apache.org said:
# Vjekoslav, can you tell me what the correct method of handling
# whitespace in base64-encoded data is? The closest thing that I found to
# a RFC on that is
# <http://www.zvon.org/tmRFC/RFC3156/Output/chapter3.html> -- it
# recommends stripping trailing whitespace. Is this what Apache's
# implementation should be doing? Or should it collapse all lines of
# base64-encoded data together, then decode that?
Sorry for jumping in, but I've got a couple comments here.
Base64 is specified in RFC 2045, which states the following:
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.
Technically speaking, the encoder was not base64 compliant (by
this spec) as it didn't break the lines at 76 characters, nor did it
ignore other characters.
--
SPY My girlfriend asked me which one I like better.
pub 1024/3CAE01D5 1994/11/03 Dustin Sallings <du...@spy.net>
| Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE
L_______________________ I hope the answer won't upset her. ____________
Re: DO NOT REPLY [Bug 9931] - Base64 decoder chokes on a
whitespace
Posted by Dustin Sallings <du...@spy.net>.
Around 23:43 on Sep 27, 2002, bugzilla@apache.org said:
# Vjekoslav, can you tell me what the correct method of handling
# whitespace in base64-encoded data is? The closest thing that I found to
# a RFC on that is
# <http://www.zvon.org/tmRFC/RFC3156/Output/chapter3.html> -- it
# recommends stripping trailing whitespace. Is this what Apache's
# implementation should be doing? Or should it collapse all lines of
# base64-encoded data together, then decode that?
Sorry for jumping in, but I've got a couple comments here.
Base64 is specified in RFC 2045, which states the following:
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.
Technically speaking, the encoder was not base64 compliant (by
this spec) as it didn't break the lines at 76 characters, nor did it
ignore other characters.
--
SPY My girlfriend asked me which one I like better.
pub 1024/3CAE01D5 1994/11/03 Dustin Sallings <du...@spy.net>
| Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE
L_______________________ I hope the answer won't upset her. ____________