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 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 ...
