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 "Niklas Therning (JIRA)" <se...@james.apache.org> on 2008/07/10 17:42:31 UTC
[jira] Created: (MIME4J-47) Nested multipart messages with
non-empty epilogue cause indefinite loop
Nested multipart messages with non-empty epilogue cause indefinite loop
-----------------------------------------------------------------------
Key: MIME4J-47
URL: https://issues.apache.org/jira/browse/MIME4J-47
Project: Mime4j
Issue Type: Bug
Affects Versions: 0.4
Reporter: Niklas Therning
I'm attaching a very simple message which causes the current version of Mime4j to loop indefinitely when the following app is run:
public static void main(String[] args) throws IOException {
String msg = "36368753.msg";
MimeTokenStream stream = new MimeTokenStream();
stream.parse(new FileInputStream(msg));
while (stream.getState() != EntityStates.T_END_OF_STREAM) {
stream.next();
}
}
If the line 'foo' is removed completely the message will parse as expected. I've tried to figure out why this happens. It seems like the MimeBoundaryInputStream becomes out of sync for the outer multipart at the end. The skipBoundary() method is called when read() is invoked even though we're not at the boundary yet which means that the end boundary won't be detected properly. One observation I did is that reset() doesn't set eof to false. If I do that in reset() the mail parses as expected:
public void reset() {
atBoundary = false;
limit = -1;
eof = false;
}
I could check in this fix myself but I do not know enough about the recent changes in Mime4j to be able to determine if this is the correct way to fix this problem.
--
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] Closed: (MIME4J-47) Nested multipart messages with non-empty
epilogue cause indefinite loop
Posted by "Niklas Therning (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Niklas Therning closed MIME4J-47.
---------------------------------
> Nested multipart messages with non-empty epilogue cause indefinite loop
> -----------------------------------------------------------------------
>
> Key: MIME4J-47
> URL: https://issues.apache.org/jira/browse/MIME4J-47
> Project: Mime4j
> Issue Type: Bug
> Affects Versions: 0.4
> Reporter: Niklas Therning
> Assignee: Niklas Therning
> Fix For: 0.4
>
> Attachments: 36368753.msg, mime4j.patch
>
>
> I'm attaching a very simple message which causes the current version of Mime4j to loop indefinitely when the following app is run:
> public static void main(String[] args) throws IOException {
> String msg = "36368753.msg";
> MimeTokenStream stream = new MimeTokenStream();
> stream.parse(new FileInputStream(msg));
>
> while (stream.getState() != EntityStates.T_END_OF_STREAM) {
> stream.next();
> }
> }
> If the line 'foo' is removed completely the message will parse as expected. I've tried to figure out why this happens. It seems like the MimeBoundaryInputStream becomes out of sync for the outer multipart at the end. The skipBoundary() method is called when read() is invoked even though we're not at the boundary yet which means that the end boundary won't be detected properly. One observation I did is that reset() doesn't set eof to false. If I do that in reset() the mail parses as expected:
> public void reset() {
> atBoundary = false;
> limit = -1;
> eof = false;
> }
> I could check in this fix myself but I do not know enough about the recent changes in Mime4j to be able to determine if this is the correct way to fix this problem.
--
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-47) Nested multipart messages with
non-empty epilogue cause indefinite loop
Posted by "Niklas Therning (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Niklas Therning updated MIME4J-47:
----------------------------------
Attachment: 36368753.msg
And here's the message
> Nested multipart messages with non-empty epilogue cause indefinite loop
> -----------------------------------------------------------------------
>
> Key: MIME4J-47
> URL: https://issues.apache.org/jira/browse/MIME4J-47
> Project: Mime4j
> Issue Type: Bug
> Affects Versions: 0.4
> Reporter: Niklas Therning
> Attachments: 36368753.msg
>
>
> I'm attaching a very simple message which causes the current version of Mime4j to loop indefinitely when the following app is run:
> public static void main(String[] args) throws IOException {
> String msg = "36368753.msg";
> MimeTokenStream stream = new MimeTokenStream();
> stream.parse(new FileInputStream(msg));
>
> while (stream.getState() != EntityStates.T_END_OF_STREAM) {
> stream.next();
> }
> }
> If the line 'foo' is removed completely the message will parse as expected. I've tried to figure out why this happens. It seems like the MimeBoundaryInputStream becomes out of sync for the outer multipart at the end. The skipBoundary() method is called when read() is invoked even though we're not at the boundary yet which means that the end boundary won't be detected properly. One observation I did is that reset() doesn't set eof to false. If I do that in reset() the mail parses as expected:
> public void reset() {
> atBoundary = false;
> limit = -1;
> eof = false;
> }
> I could check in this fix myself but I do not know enough about the recent changes in Mime4j to be able to determine if this is the correct way to fix this problem.
--
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-47) Nested multipart messages with
non-empty epilogue cause indefinite loop
Posted by "Niklas Therning (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Niklas Therning resolved MIME4J-47.
-----------------------------------
Resolution: Fixed
Fix Version/s: 0.4
Thanks Oleg, your patch has been applied.
> Nested multipart messages with non-empty epilogue cause indefinite loop
> -----------------------------------------------------------------------
>
> Key: MIME4J-47
> URL: https://issues.apache.org/jira/browse/MIME4J-47
> Project: Mime4j
> Issue Type: Bug
> Affects Versions: 0.4
> Reporter: Niklas Therning
> Assignee: Niklas Therning
> Fix For: 0.4
>
> Attachments: 36368753.msg, mime4j.patch
>
>
> I'm attaching a very simple message which causes the current version of Mime4j to loop indefinitely when the following app is run:
> public static void main(String[] args) throws IOException {
> String msg = "36368753.msg";
> MimeTokenStream stream = new MimeTokenStream();
> stream.parse(new FileInputStream(msg));
>
> while (stream.getState() != EntityStates.T_END_OF_STREAM) {
> stream.next();
> }
> }
> If the line 'foo' is removed completely the message will parse as expected. I've tried to figure out why this happens. It seems like the MimeBoundaryInputStream becomes out of sync for the outer multipart at the end. The skipBoundary() method is called when read() is invoked even though we're not at the boundary yet which means that the end boundary won't be detected properly. One observation I did is that reset() doesn't set eof to false. If I do that in reset() the mail parses as expected:
> public void reset() {
> atBoundary = false;
> limit = -1;
> eof = false;
> }
> I could check in this fix myself but I do not know enough about the recent changes in Mime4j to be able to determine if this is the correct way to fix this problem.
--
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-47) Nested multipart messages with
non-empty epilogue cause indefinite loop
Posted by "Niklas Therning (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Niklas Therning reassigned MIME4J-47:
-------------------------------------
Assignee: Niklas Therning
> Nested multipart messages with non-empty epilogue cause indefinite loop
> -----------------------------------------------------------------------
>
> Key: MIME4J-47
> URL: https://issues.apache.org/jira/browse/MIME4J-47
> Project: Mime4j
> Issue Type: Bug
> Affects Versions: 0.4
> Reporter: Niklas Therning
> Assignee: Niklas Therning
> Attachments: 36368753.msg, mime4j.patch
>
>
> I'm attaching a very simple message which causes the current version of Mime4j to loop indefinitely when the following app is run:
> public static void main(String[] args) throws IOException {
> String msg = "36368753.msg";
> MimeTokenStream stream = new MimeTokenStream();
> stream.parse(new FileInputStream(msg));
>
> while (stream.getState() != EntityStates.T_END_OF_STREAM) {
> stream.next();
> }
> }
> If the line 'foo' is removed completely the message will parse as expected. I've tried to figure out why this happens. It seems like the MimeBoundaryInputStream becomes out of sync for the outer multipart at the end. The skipBoundary() method is called when read() is invoked even though we're not at the boundary yet which means that the end boundary won't be detected properly. One observation I did is that reset() doesn't set eof to false. If I do that in reset() the mail parses as expected:
> public void reset() {
> atBoundary = false;
> limit = -1;
> eof = false;
> }
> I could check in this fix myself but I do not know enough about the recent changes in Mime4j to be able to determine if this is the correct way to fix this problem.
--
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-47) Nested multipart messages with
non-empty epilogue cause indefinite loop
Posted by "Oleg Kalnichevski (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski updated MIME4J-47:
------------------------------------
Attachment: mime4j.patch
My bad. The fix looks reasonable to me. Attaching a patch with an additional test case just in case.
Oleg
> Nested multipart messages with non-empty epilogue cause indefinite loop
> -----------------------------------------------------------------------
>
> Key: MIME4J-47
> URL: https://issues.apache.org/jira/browse/MIME4J-47
> Project: Mime4j
> Issue Type: Bug
> Affects Versions: 0.4
> Reporter: Niklas Therning
> Attachments: 36368753.msg, mime4j.patch
>
>
> I'm attaching a very simple message which causes the current version of Mime4j to loop indefinitely when the following app is run:
> public static void main(String[] args) throws IOException {
> String msg = "36368753.msg";
> MimeTokenStream stream = new MimeTokenStream();
> stream.parse(new FileInputStream(msg));
>
> while (stream.getState() != EntityStates.T_END_OF_STREAM) {
> stream.next();
> }
> }
> If the line 'foo' is removed completely the message will parse as expected. I've tried to figure out why this happens. It seems like the MimeBoundaryInputStream becomes out of sync for the outer multipart at the end. The skipBoundary() method is called when read() is invoked even though we're not at the boundary yet which means that the end boundary won't be detected properly. One observation I did is that reset() doesn't set eof to false. If I do that in reset() the mail parses as expected:
> public void reset() {
> atBoundary = false;
> limit = -1;
> eof = false;
> }
> I could check in this fix myself but I do not know enough about the recent changes in Mime4j to be able to determine if this is the correct way to fix this problem.
--
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