[
https://issues.apache.org/jira/browse/MIME4J-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12613323#action_12613323
]
Stefano Bagnara commented on MIME4J-54:
---------------------------------------
RFC states boundaries having 0 or more spaces at the end of the boundary before
the CRLF should be correctly interpreted as boundaries.
from the rfc:
================================
encapsulation := delimiter transport-padding
CRLF body-part
================================
and also
================================
"Composers MUST NOT generate non-zero length transport
padding, but receivers MUST be able to handle padding
added by message transports."
================================
I added this check to "intermediate-boundaries.msg"
The rfc also report this text while discussing the ending boundary:
==================================
NOTE TO IMPLEMENTORS: Boundary string comparisons must compare the
boundary value with the beginning of each candidate line. An exact
match of the entire candidate line is not required; it is sufficient
that the boundary appear in its entirety following the CRLF.
=====================================
How do you read it?
Is a line having "--XXX--something" a correct ending delimiter for the "XXX"
boundary?
Does this apply to intermediate delimiters?
I already created test messages and expected results, but we should fix
expected results based on our understanding of the rfc first, and then try to
fix the code.
> boundaries should only be found at the beginning of a line
> ----------------------------------------------------------
>
> Key: MIME4J-54
> URL: https://issues.apache.org/jira/browse/MIME4J-54
> Project: Mime4j
> Issue Type: Bug
> Affects Versions: 0.4
> Reporter: Stefano Bagnara
> Fix For: 0.4
>
>
> current mime4j seems to be fooled by mime boundaries inside lines of text
> parts (not at the beginnning of a line).
> I committed misplaced-boundary.msg example message to show the issue and the
> expected result.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
