You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mime4j-dev@james.apache.org by "Stefano Bagnara (JIRA)" <mi...@james.apache.org> on 2010/01/03 16:55:54 UTC
[jira] Created: (MIME4J-161) QuotedPrintableInputStream may be
lenient with newlines but should be consistent in decoded data.
QuotedPrintableInputStream may be lenient with newlines but should be consistent in decoded data.
-------------------------------------------------------------------------------------------------
Key: MIME4J-161
URL: https://issues.apache.org/jira/browse/MIME4J-161
Project: JAMES Mime4j
Issue Type: Task
Affects Versions: 0.6
Reporter: Stefano Bagnara
Assignee: Stefano Bagnara
Priority: Minor
Fix For: 0.8
Currently quotedprintableinputstreams treat the CRLF or LF as a full CRLF, translating single LF to CRLF while decoding, but not consistently.
In fact if a qpstream ends with "somethingLF" the decoded result ends with "somethingLF" while if it ends with "somethingCRLF" the decoded result is "something" (no CRLF). This is inconsistent and I consider this a bug. IF LF is considered the same as CRLF it should be the same also if it is at the end of a stream.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MIME4J-161) QuotedPrintableInputStream may be
lenient with newlines but should be consistent in decoded data.
Posted by "Stefano Bagnara (JIRA)" <mi...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796030#action_12796030 ]
Stefano Bagnara commented on MIME4J-161:
----------------------------------------
testDecodeEndOfStream3 currently checks that decoding "012345\n" results in "012345\n". So, most time QuotedPrintableInputStreams translated lonely LF to CRLF but not if this is the last byte of the stream. Sounds like a bug.
QuotedPrintableTextEncode.testLetterEncoding checks that a simple byte decoding result in the same byte excluding CR, SP, HTAB. IMO also LF should be included here once the previous bug is fixed (if we always treat LF as CRLF then decoding a lone LF should result in CRLF).
> QuotedPrintableInputStream may be lenient with newlines but should be consistent in decoded data.
> -------------------------------------------------------------------------------------------------
>
> Key: MIME4J-161
> URL: https://issues.apache.org/jira/browse/MIME4J-161
> Project: JAMES Mime4j
> Issue Type: Task
> Affects Versions: 0.6
> Reporter: Stefano Bagnara
> Assignee: Stefano Bagnara
> Priority: Minor
> Fix For: 0.8
>
>
> Currently quotedprintableinputstreams treat the CRLF or LF as a full CRLF, translating single LF to CRLF while decoding, but not consistently.
> In fact if a qpstream ends with "somethingLF" the decoded result ends with "somethingLF" while if it ends with "somethingCRLF" the decoded result is "something" (no CRLF). This is inconsistent and I consider this a bug. IF LF is considered the same as CRLF it should be the same also if it is at the end of a stream.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MIME4J-161) QuotedPrintableInputStream may be
lenient with newlines but should be consistent in decoded data.
Posted by "Stefano Bagnara (JIRA)" <mi...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefano Bagnara resolved MIME4J-161.
------------------------------------
Resolution: Fixed
Merged from cycleclean.
> QuotedPrintableInputStream may be lenient with newlines but should be consistent in decoded data.
> -------------------------------------------------------------------------------------------------
>
> Key: MIME4J-161
> URL: https://issues.apache.org/jira/browse/MIME4J-161
> Project: JAMES Mime4j
> Issue Type: Task
> Affects Versions: 0.6
> Reporter: Stefano Bagnara
> Assignee: Stefano Bagnara
> Priority: Minor
> Fix For: 0.7
>
>
> Currently quotedprintableinputstreams treat the CRLF or LF as a full CRLF, translating single LF to CRLF while decoding, but not consistently.
> In fact if a qpstream ends with "somethingLF" the decoded result ends with "somethingLF" while if it ends with "somethingCRLF" the decoded result is "something" (no CRLF). This is inconsistent and I consider this a bug. IF LF is considered the same as CRLF it should be the same also if it is at the end of a stream.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.