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