james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: svn commit: r1094982
Date Tue, 19 Apr 2011 15:17:27 GMT
On Tue, 2011-04-19 at 17:08 +0200, Stefano Bagnara wrote:
> 2011/4/19 Oleg Kalnichevski <olegk@apache.org>:
> > On Tue, 2011-04-19 at 16:32 +0200, Oleg Kalnichevski wrote:
> >> On Tue, 2011-04-19 at 09:57 +0000, bago@apache.org wrote:
> >> > Author: bago
> >> > Date: Tue Apr 19 09:57:36 2011
> >> > New Revision: 1094982
> >> >
> >> > URL: http://svn.apache.org/viewvc?rev=1094982&view=rev
> >> > Log:
> >> > Added some more testmsgs generated by me
> >> >
> >>
> >> Stefano
> >>
> >> I am seeing a number of failures in the test cases. Are these test cases
> >> expected to fail or is this on oversight?
> >>
> >> As far as I can tell presently the mime stream parser chokes on
> >> boundaries with white space characters in them. What should be the
> >> expected behavior?
> >>
> >> ---
> >> Tests in error:
> >>
> >> badbound.msg(org.apache.james.mime4j.parser.MimeStreamParserExampleMessagesTest):
Boundary may not contain CR or LF
> >>
> >> multi-clen.msg(org.apache.james.mime4j.parser.MimeStreamParserExampleMessagesTest):
Boundary may not contain CR or LF
> >>
> >> multi-badnames.msg(org.apache.james.mime4j.parser.MimeStreamParserExampleMessagesTest):
Boundary may not contain CR or LF
> >>
> >> multi-simple.msg(org.apache.james.mime4j.parser.MimeStreamParserExampleMessagesTest):
Boundary may not contain CR or LF
> >>
> >> multi-digest.msg(org.apache.james.mime4j.parser.MimeStreamParserExampleMessagesTest):
Boundary may not contain CR or LF
> >> ---
> >>
> >> Cheers
> >>
> >> Oleg
> >>
> >
> > Stefano,
> >
> > Actually looks like mime4j is perfectly capable of parsing these
> > messages despite of the boundary containing illegal characters.
> >
> > Could you please review those messages and adjust expectations in the
> > test cases if that makes sense?
> 
> >From my reading of the RFC a boundary can contain a space. When the
> boundary contains a space the header folding algorythm is allowed to
> fold the header right where the space is present.
> So, you should make sure RawFieldParser correclty unfold the header
> before/while parsing it. This way the messages will get parsed
> correctly, right?
> 
> Here is a MIME message from http://www.faqs.org/rfcs/rfc1341.html
> 
> -----
> From: Nathaniel Borenstein <nsb@bellcore.com>
> To:  Ned Freed <ned@innosoft.com>
> Subject: Sample message
> MIME-Version: 1.0
> Content-type: multipart/mixed; boundary="simple
>  boundary"
> 
> This is the preamble.  It is to be ignored, though it
> is a handy place for mail composers to include an
> explanatory note to non-MIME compliant readers.
> --simple boundary
> 
> This is implicitly typed plain ASCII text.
> It does NOT end with a linebreak.
> --simple boundary
> Content-type: text/plain; charset=us-ascii
> 
> This is explicitly typed plain ASCII text.
> It DOES end with a linebreak.
> 
> --simple boundary--
> This is the epilogue.  It is also to be ignored.
> ------
> 
> As you can see the boundary contains a space and is folded. From my
> test mime4j currently fails to correctly parse this. But this is what
> I remember from a test done few days ago. If you think this is not the
> case I will check better and open a more detailed JIRA issue.
> 
> Stefano
> 

I see. Makes sense. 

I am currently in the process of rewriting the low level field parsing
code to make it capable of dealing with comments. I'll fix the
regression as soon as that work is completed.

Please do not commit failing test cases even if those test cases are for
a known regression, though. The respective JIRA issue should probably a
better place for such test cases. 

Oleg


Mime
View raw message