RFR 8025003: Base64 should be less strict with padding

[Bill Shannon]

Have you had a chance to think about this?  Can the MIME decoder be made
more lenient, or can I get an option to control this?

Bill Shannon wrote on 10/25/13 15:24:
> Xueming Shen wrote on 10/25/13 15:19:
>> On 10/25/13 2:19 PM, Bill Shannon wrote:
>>> If I understand this correctly, this proposes to remove the "lenient"
>>> option we've been discussing and just make it always lenient.  Is that
>>> correct?
>>
>> Yes. Only for the mime type though.
> 
> That's fine.
> 
>>> Unfortunately, from what you say below, it's still not lenient enough.
>>> I'd really like a version that never, ever, for any reason, throws an
>>> exception.  Yes, that means when you only get a final 6 bits of data
>>> you have to make an assumption about what was intended, probably padding
>>> it with zeros to 8 bits.
>>
>> This is something I'm hesitated to do. I can be lenient for the padding end
>> because the
>> padding character itself is not the real "data", whether or not it's present,
>> it's missing or
>> it's incorrect/incomplete, it does not impact the integrity of the data. But to
>> feed the last
>> 6 bits with zero, is really kinda of guessing, NOT decoding.
> 
> I understand.  And if the people who write spamming software knew how to
> read a spec, we wouldn't have this problem!  :-)
> 
> Still, there's a lot of bad data out there on the internet, and people
> want the software to do the best job it can to interpret the data.  It's
> better to guess at the missing 2 bits of data than to lose the last 6 bits
> of data.