[
https://issues.apache.org/jira/browse/MIME4J-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clément Denis updated MIME4J-160:
---------------------------------
Attachment: quotedprintablewithoutencoding.mime
> 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.0
>
> Attachments: quotedprintablewithoutencoding.mime
>
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
