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 Daniel Rall <dl...@finemaltcoding.com> on 2002/09/28 01:42:42 UTC
Re: base64 interop problems
Dustin Sallings <du...@spy.net> writes:
> Around 14:39 on Jul 1, 2002, Daniel Rall said:
>
> # Hey Dustin. Is this be related to issue 9931, "Base64 decoder chokes on
> # a whitespace?"
> #
> # http://issues.apache.org/bugzilla/show_bug.cgi?id=9931
>
> Well, that'd be exactly my problem. :)
>
> Sorry for not investigating further. My goal was to make my
> application work, and after doing so, I thought someone else would
> probably have had the same problem I did. I looked around for list
> archives, but didn't think to look for a bug tracking system.
>
> Anyway, the one I sent in also does not throw an exception, and
> may ``succesfully'' decode something that got corrupt and contains invalid
> characters as it ignores any invalid characters (easy to fix, as stated in
> my original mail), but the behavior does seem more correct. At least, my
> application is working between java and python now.
Dustin, would you comment on that issue listed above? Your patch came
through as changing the entire Base64.java file, rather than just a
small section of code.
Thanks, Dan
--
Daniel Rall <dl...@finemaltcoding.com>
Re: base64 interop problems
Posted by Dustin Sallings <du...@spy.net>.
Around 14:04 on Sep 28, 2002, John Wilson said:
# Did you look at the performance of your new version? The existing code
# is not as fast as it could be. It would be very nice if you have
# improved performance as well as fixing a bug :-)
I didn't do a comparison, but I'm sure it's not too bad. I bet I
could find some places to speed it up if I tried, just need a test
framework.
--
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: base64 interop problems
Posted by Dustin Sallings <du...@spy.net>.
Around 14:04 on Sep 28, 2002, John Wilson said:
# Did you look at the performance of your new version? The existing code
# is not as fast as it could be. It would be very nice if you have
# improved performance as well as fixing a bug :-)
I didn't do a comparison, but I'm sure it's not too bad. I bet I
could find some places to speed it up if I tried, just need a test
framework.
--
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: base64 interop problems
Posted by John Wilson <tu...@wilson.co.uk>.
----- Original Message -----
From: "Dustin Sallings" <du...@spy.net>
To: "Daniel Rall" <dl...@finemaltcoding.com>
Cc: <rp...@xml.apache.org>
Sent: Saturday, September 28, 2002 12:56 AM
Subject: Re: base64 interop problems
[snip]
> The issue is the handling of non-base64 data in the input of the
> decoder. The base64 decoder attempts to decode every character in the
> input stream. The one I provided skips characters that are not base64
> characters. A third behavior is probably more appropriate: skip only
> whitespace characters and throw an exception on non-whitespace, non-base64
> characters.
Yes I think that it is better to throw an exception on non whitespace.
Did you look at the performance of your new version? The existing code is
not as fast as it could be. It would be very nice if you have improved
performance as well as fixing a bug :-)
John Wilson
The Wilson Partnership
http://www.wilson.co.uk
Re: base64 interop problems
Posted by John Wilson <tu...@wilson.co.uk>.
----- Original Message -----
From: "Dustin Sallings" <du...@spy.net>
To: "Daniel Rall" <dl...@finemaltcoding.com>
Cc: <rp...@xml.apache.org>
Sent: Saturday, September 28, 2002 12:56 AM
Subject: Re: base64 interop problems
[snip]
> The issue is the handling of non-base64 data in the input of the
> decoder. The base64 decoder attempts to decode every character in the
> input stream. The one I provided skips characters that are not base64
> characters. A third behavior is probably more appropriate: skip only
> whitespace characters and throw an exception on non-whitespace, non-base64
> characters.
Yes I think that it is better to throw an exception on non whitespace.
Did you look at the performance of your new version? The existing code is
not as fast as it could be. It would be very nice if you have improved
performance as well as fixing a bug :-)
John Wilson
The Wilson Partnership
http://www.wilson.co.uk
Re: base64 interop problems
Posted by Dustin Sallings <du...@spy.net>.
Around 16:42 on Sep 27, 2002, Daniel Rall said:
# Dustin, would you comment on that issue listed above? Your patch came
# through as changing the entire Base64.java file, rather than just a
# small section of code.
Yeah, I just needed to get it running, so I didn't try to fix what
was there (well, I did, but I didn't spend a lot of time in it). Instead,
I replaced it with one I'd written that I knew works.
I ran into the problem when adding XML-RPC support to an
application I've written (in java) that moves photographs around, and then
creating a standalone app (in python) to talk to it. The data size was
not the same upon decoding as it was before sending it up. With the
changes I've made, it seems to work very well. I now have clients written
in python (xmlrpclib), java (using this framework), perl (I didn't write
the perl one, but it works), and objective C (using a framework built upon
xmlrpc-c) all working with the application now.
The issue is the handling of non-base64 data in the input of the
decoder. The base64 decoder attempts to decode every character in the
input stream. The one I provided skips characters that are not base64
characters. A third behavior is probably more appropriate: skip only
whitespace characters and throw an exception on non-whitespace, non-base64
characters.
I hope that's clear, it's Friday. :)
--
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: base64 interop problems
Posted by Dustin Sallings <du...@spy.net>.
Around 16:42 on Sep 27, 2002, Daniel Rall said:
# Dustin, would you comment on that issue listed above? Your patch came
# through as changing the entire Base64.java file, rather than just a
# small section of code.
Yeah, I just needed to get it running, so I didn't try to fix what
was there (well, I did, but I didn't spend a lot of time in it). Instead,
I replaced it with one I'd written that I knew works.
I ran into the problem when adding XML-RPC support to an
application I've written (in java) that moves photographs around, and then
creating a standalone app (in python) to talk to it. The data size was
not the same upon decoding as it was before sending it up. With the
changes I've made, it seems to work very well. I now have clients written
in python (xmlrpclib), java (using this framework), perl (I didn't write
the perl one, but it works), and objective C (using a framework built upon
xmlrpc-c) all working with the application now.
The issue is the handling of non-base64 data in the input of the
decoder. The base64 decoder attempts to decode every character in the
input stream. The one I provided skips characters that are not base64
characters. A third behavior is probably more appropriate: skip only
whitespace characters and throw an exception on non-whitespace, non-base64
characters.
I hope that's clear, it's Friday. :)
--
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. ____________