You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xmlrpc-dev@ws.apache.org by Ryan Hoegg <rh...@isisnetworks.net> on 2003/02/03 20:52:35 UTC
[Fwd: Re: Moving Base64 in HttpClient to commons-codec]
Looks like the appropriate people have been made aware.
Thanks for checking that one out, Martin!
--
Ryan Hoegg
ISIS Networks'http://www.isisnetworks.net
Re: [Fwd: Re: Moving Base64 in HttpClient to commons-codec]
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Actually from the thread in eyebrowse it looks like they are taking your
version of the class from CVS or maybe from Bugzilla. Tim definitely
seems to think our Base64 is the one to use from the lot.
Martin Redington wrote:
> Hi Ryan,
>
> I would get my additional changes in (or at least bring them to
> Tim's attention), as they are a definite step forward, in terms of
> both RFC compliance and efficiency (Danny's comment about trailing
> CR/LF's not withstanding) ...
>
> On Monday, February 3, 2003, at 10:33 PM, Ryan Hoegg wrote:
>
>> I think I'm going to back off any further changes as it looks like
>> this has turned into an Apache-wide thing now:
>>
>> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=commons-
>> dev@jakarta.apache.org&msgNo=23792
>>
>> Tim O'Brien says there are 35 (!) active classes throughout Apache
>> using this code. After the dust settles we should probably move
>> further discussion of this to the Commons-dev list so the Codec
>> committers can participate.
>>
>> Anyone have input on how to introduce the runtime dependency?
>> Daniel's point about the classloader keeps nagging at me. Perhaps
>> include a link to the Codec JAR on our installation instructions?
>
Re: [Fwd: Re: Moving Base64 in HttpClient to commons-codec]
Posted by Martin Redington <m....@ucl.ac.uk>.
Hi Ryan,
I would get my additional changes in (or at least bring them to
Tim's attention), as they are a definite step forward, in terms of both
RFC compliance and efficiency (Danny's comment about trailing CR/LF's
not withstanding) ...
On Monday, February 3, 2003, at 10:33 PM, Ryan Hoegg wrote:
> I think I'm going to back off any further changes as it looks like
> this has turned into an Apache-wide thing now:
>
> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=commons-
> dev@jakarta.apache.org&msgNo=23792
>
> Tim O'Brien says there are 35 (!) active classes throughout Apache
> using this code. After the dust settles we should probably move
> further discussion of this to the Commons-dev list so the Codec
> committers can participate.
>
> Anyone have input on how to introduce the runtime dependency?
> Daniel's point about the classloader keeps nagging at me. Perhaps
> include a link to the Codec JAR on our installation instructions?
Re: [Fwd: Re: Moving Base64 in HttpClient to commons-codec]
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
I think I'm going to back off any further changes as it looks like this
has turned into an Apache-wide thing now:
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=commons-dev@jakarta.apache.org&msgNo=23792
Tim O'Brien says there are 35 (!) active classes throughout Apache using
this code. After the dust settles we should probably move further
discussion of this to the Commons-dev list so the Codec committers can
participate.
Anyone have input on how to introduce the runtime dependency? Daniel's
point about the classloader keeps nagging at me. Perhaps include a link
to the Codec JAR on our installation instructions?
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
Martin Redington wrote:
> Well, here is what the RFC says:
>
> RFC 2045
>
> from section 6.8
>
> 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.
>
> I think that the last sentence is equivalent to MAY in RFC-speak, so
> the patch "as is" makes us RFC-compliant.
>
> I think the most conservative (least change) approach, and my
> instinctive reaction is to ignore non base64 chars for now (which is
> no worse than the current non-RFC compliant version) and see if anyone
> files a bug.
>
> OTOH, non-base64 characters are almost certain to be transmission
> errors, so you may well be doing the end-user a big favour by throwing
> an exception with a clear message.
>
> I believe there's a comment in the patched code indicating where the
> exception should go, so if you favour the latter approach, just stick
> one in ...
>
Re: [Fwd: Re: Moving Base64 in HttpClient to commons-codec]
Posted by Martin Redington <m....@ucl.ac.uk>.
On Monday, February 3, 2003, at 08:37 PM, Ryan Hoegg wrote:
> I've seen these fly by as you have been updating the Bug. I imagine
> most of these are Good Things, but I think the Codec people will have
> concerns about silently ignoring things the RFC encourages us to
> complain about. You think we should raise some sort of exception?
Well, here is what the RFC says:
RFC 2045
from section 6.8
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.
I think that the last sentence is equivalent to MAY in RFC-speak, so
the patch "as is" makes us RFC-compliant.
I think the most conservative (least change) approach, and my
instinctive reaction is to ignore non base64 chars for now (which is no
worse than the current non-RFC compliant version) and see if anyone
files a bug.
OTOH, non-base64 characters are almost certain to be transmission
errors, so you may well be doing the end-user a big favour by throwing
an exception with a clear message.
I believe there's a comment in the patched code indicating where the
exception should go, so if you favour the latter approach, just stick
one in ...
Re: [Fwd: Re: Moving Base64 in HttpClient to commons-codec]
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
I've seen these fly by as you have been updating the Bug. I imagine
most of these are Good Things, but I think the Codec people will have
concerns about silently ignoring things the RFC encourages us to
complain about. You think we should raise some sort of exception?
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
Martin Redington wrote:
> np, but you might want to check out my most recent patches on bug 9931.
>
> These added:
>
> a final newline to encoded data (which seems to be RFC compliant, as
> lines are supposed to be folded as "at most" 76 characters, and this
> is also how the Perl base64 behaves).
>
> discarding of whitespace and any non-base64 chars in decode() [which
> is RFC compliant, although the RFC encourages an exception or warning
> if non-base64 chars are detected].
>
> significant speedups (about 50%) to decode(). The Vectors slowed the
> old version down quite a bit.
>
> There was also a patch to Base64Test that fixed a few minor issues
> (and is necessary for the "final newline" change above to pass the
> tests).
>
>
> If you have any q's or problems with the patches let me know ...
>
> cheers,
> m.
>
>
Re: [Fwd: Re: Moving Base64 in HttpClient to commons-codec]
Posted by Martin Redington <m....@ucl.ac.uk>.
On Monday, February 3, 2003, at 07:52 PM, Ryan Hoegg wrote:
> Looks like the appropriate people have been made aware.
>
> Thanks for checking that one out, Martin!
np, but you might want to check out my most recent patches on bug 9931.
These added:
a final newline to encoded data (which seems to be RFC compliant, as
lines are supposed to be folded as "at most" 76 characters, and this is
also how the Perl base64 behaves).
discarding of whitespace and any non-base64 chars in decode() [which is
RFC compliant, although the RFC encourages an exception or warning if
non-base64 chars are detected].
significant speedups (about 50%) to decode(). The Vectors slowed the
old version down quite a bit.
There was also a patch to Base64Test that fixed a few minor issues (and
is necessary for the "final newline" change above to pass the tests).
If you have any q's or problems with the patches let me know ...
cheers,
m.