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 t
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 Hoe
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?[EMAIL PROTECTED]&msgNo=23792
Tim O'Brien says there are 35 (!) active classes throughout Apache using
this code. After the dust settles
> 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).
Yup, Base64 is a mail transport encoding defined in
http://www.ietf.org/rfc/rfc1521.txt for transport of MIME dat
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
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 Netwo
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
