Document/describe how QuotedPrintable/Base64 decoding deal with unexpected
input sequences and if we need multiple behaviour supports or not.
---------------------------------------------------------------------------------------------------------------------------------------------
Key: MIME4J-160
URL: https://issues.apache.org/jira/browse/MIME4J-160
Project: JAMES Mime4j
Issue Type: Task
Affects Versions: 0.6
Reporter: Stefano Bagnara
Priority: Minor
Fix For: 0.8
Base64 should "die" on unexpected content, but MIME says that any char outside
the "charset" should be ignored, because at least CR and LF are expected to
appear in mime base64 streams. Should a strict base64 decoder die on some other
char or not?
QuotedPrintable currently handle these 2 malformations:
== translated to =
=XX on invalid XX is left as is (=XX)
Some other decoder have different strategies:
some of them match =[hex]?[hex]? some of them match =[any][any] (see how this
alter the interpretation of a =X=A=BB sequence)
after matching the treat invalid sequences differently, too. Some of them
output the invalid sequence as is, some of them output it without the "=", some
other remove the whole sequence from the stream.
The same applies with dealing with space at the end of a line: some
implementation leave it as is, some other implementation removes it.
I tried searching the RFC to understand if there is a preferred strategy to
deal with malformed sequences but I had no success, maybe I've missed
something. Any opinion?
As I know that we rewrote the QuotedPrintableInputStream multiple times, I'd
like to head opinions about dealing with malformations.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
