You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Stefano Bagnara (JIRA)" <se...@james.apache.org> on 2008/07/14 16:12:31 UTC
[jira] Created: (MIME4J-55) Infinite loop on very long boundary
(7000 chars)
Infinite loop on very long boundary (7000 chars)
------------------------------------------------
Key: MIME4J-55
URL: https://issues.apache.org/jira/browse/MIME4J-55
Project: Mime4j
Issue Type: Bug
Reporter: Stefano Bagnara
Fix For: 0.4
RFC does not mandate parsing of a boundary of that size, but for sure we should avoid an infinite loop.
I committed very-very-long-boundary.msg as a proof.
--
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-55) Infinite loop on very long boundary
(7000 chars)
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12614347#action_12614347 ]
Stefano Bagnara commented on MIME4J-55:
---------------------------------------
I created MIME4J-57 for the header length issue.
Maybe we can move that issue to a following release (0.5), I don't have a strong opinion on this.
About me committing to trunk I think I explained why I behaved differently in the "collaboration & branches" message (it was not intended to become a dev branch, only a show you that refactoring branch, but something different happened not under my control and needed review from the team).
I just committed your patch to the streams-refactoring branch.
I didn't commit the EOL conversion of the expected files: they should be committed in binary form because we want to also fail on different expected/actual EOLs.
I think there is an issue with mime streams ending with \n that are not converted to \r\n, but I'll open a JIRA once I'll have verified this.
> Infinite loop on very long boundary (7000 chars)
> ------------------------------------------------
>
> Key: MIME4J-55
> URL: https://issues.apache.org/jira/browse/MIME4J-55
> Project: Mime4j
> Issue Type: Bug
> Reporter: Stefano Bagnara
> Fix For: 0.4
>
> Attachments: mime4j.patch
>
>
> RFC does not mandate parsing of a boundary of that size, but for sure we should avoid an infinite loop.
> I committed very-very-long-boundary.msg as a proof.
--
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Updated: (MIME4J-55) Infinite loop on very long boundary
(7000 chars)
Posted by "Oleg Kalnichevski (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski updated MIME4J-55:
------------------------------------
Attachment: mime4j.patch
The patch attached enables mime4j to parse messages with boundaries of arbitrary length. Please review.
The parch is against the streaming-branch
Stefano,
Could you _please_ merge the streaming-branch up to the trunk? It is extremely inconvenient to have the latest code spread over 3 different branches. No one seems to object merging the changes off the streaming-branch to the trunk.
Feel free to add whatever expected results for the very-very-long-boundary.msg you deem reasonable.
Cheers
Oleg
> Infinite loop on very long boundary (7000 chars)
> ------------------------------------------------
>
> Key: MIME4J-55
> URL: https://issues.apache.org/jira/browse/MIME4J-55
> Project: Mime4j
> Issue Type: Bug
> Reporter: Stefano Bagnara
> Fix For: 0.4
>
> Attachments: mime4j.patch
>
>
> RFC does not mandate parsing of a boundary of that size, but for sure we should avoid an infinite loop.
> I committed very-very-long-boundary.msg as a proof.
--
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-55) Infinite loop on very long boundary
(7000 chars)
Posted by "Oleg Kalnichevski (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12614335#action_12614335 ]
Oleg Kalnichevski commented on MIME4J-55:
-----------------------------------------
> Do you think we have to put a limit somewhere to the boundary length we allow to avoid a very long boundary to make
> us allocating very big buffers?
I think it would be much better and cleaner to enforce a max limit on header length. This would automatically take care of very long boundaries. This said, can we please take care of fringe cases after 0.4 release? Like _please_?
> About merging code to trunk I'll do this as soon as we solved the incomprehension about my use of the branch, I'm sure
> this won't take too much!
As far as I am concerned you should have just committed your changes to trunk and be done with it. Would it then be a big deal for you to commit the patch to the streaming-branch so I could go ahead with fixing other outstanding issues?
Oleg
> Infinite loop on very long boundary (7000 chars)
> ------------------------------------------------
>
> Key: MIME4J-55
> URL: https://issues.apache.org/jira/browse/MIME4J-55
> Project: Mime4j
> Issue Type: Bug
> Reporter: Stefano Bagnara
> Fix For: 0.4
>
> Attachments: mime4j.patch
>
>
> RFC does not mandate parsing of a boundary of that size, but for sure we should avoid an infinite loop.
> I committed very-very-long-boundary.msg as a proof.
--
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Assigned: (MIME4J-55) Infinite loop on very long boundary
(7000 chars)
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefano Bagnara reassigned MIME4J-55:
-------------------------------------
Assignee: Stefano Bagnara
> Infinite loop on very long boundary (7000 chars)
> ------------------------------------------------
>
> Key: MIME4J-55
> URL: https://issues.apache.org/jira/browse/MIME4J-55
> Project: Mime4j
> Issue Type: Bug
> Reporter: Stefano Bagnara
> Assignee: Stefano Bagnara
> Fix For: 0.4
>
> Attachments: mime4j.patch
>
>
> RFC does not mandate parsing of a boundary of that size, but for sure we should avoid an infinite loop.
> I committed very-very-long-boundary.msg as a proof.
--
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Resolved: (MIME4J-55) Infinite loop on very long boundary
(7000 chars)
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefano Bagnara resolved MIME4J-55.
-----------------------------------
Resolution: Fixed
Branch has been merged.
> Infinite loop on very long boundary (7000 chars)
> ------------------------------------------------
>
> Key: MIME4J-55
> URL: https://issues.apache.org/jira/browse/MIME4J-55
> Project: Mime4j
> Issue Type: Bug
> Reporter: Stefano Bagnara
> Assignee: Stefano Bagnara
> Fix For: 0.4
>
> Attachments: mime4j.patch
>
>
> RFC does not mandate parsing of a boundary of that size, but for sure we should avoid an infinite loop.
> I committed very-very-long-boundary.msg as a proof.
--
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-55) Infinite loop on very long boundary
(7000 chars)
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12614332#action_12614332 ]
Stefano Bagnara commented on MIME4J-55:
---------------------------------------
The patch seems ok to me!
Do you think we have to put a limit somewhere to the boundary length we allow to avoid a very long boundary to make us allocating very big buffers? Maybe this limit has to be placed during the boundary header decoding? What should the fallback behaviour be in this case? (maybe parse it as a non multipart?)
About merging code to trunk I'll do this as soon as we solved the incomprehension about my use of the branch, I'm sure this won't take too much!
Thank you!
> Infinite loop on very long boundary (7000 chars)
> ------------------------------------------------
>
> Key: MIME4J-55
> URL: https://issues.apache.org/jira/browse/MIME4J-55
> Project: Mime4j
> Issue Type: Bug
> Reporter: Stefano Bagnara
> Fix For: 0.4
>
> Attachments: mime4j.patch
>
>
> RFC does not mandate parsing of a boundary of that size, but for sure we should avoid an infinite loop.
> I committed very-very-long-boundary.msg as a proof.
--
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org