james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: svn commit: r1094982
Date Tue, 19 Apr 2011 15:20:21 GMT
> 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?

I just committed a testcase for RawFieldParserTest to show that the
parser doesn't correctly deal with folded headers.
I don't know if in your logic RawFieldParser should be the one doing
the unfolding or instead if client code should unfold before calling
RawFieldParser but this must be done somewhere.

At the moment DefaultBodyDescriptor use this method:
    private void parseContentType(RawField field) throws MimeException {
        contentTypeSet = true;
        RawBody body = RawFieldParser.DEFAULT.parseRawBody(field);
        String main = body.getValue();

And here is the problematic code:

    public RawBody parseRawBody(final RawField field) {
        ByteSequence buf = field.getRaw();
        int pos = field.getDelimiterIdx() + 1;
        if (buf == null) {
            String body = field.getBody();
            if (body == null) {
                return new RawBody("", null);
            buf = ContentUtil.encode(body);
            pos = 0;
        ParserCursor cursor = new ParserCursor(pos, buf.length());
        return parseRawBody(buf, cursor);
field.getRaw returns the original folded header.
instead field.getBody returns a decoded & *unfoded* header.
While in this last step you make sure to run "encoding", in the first
there is no unfolding or in the last there is no folding. The should
be equals once you reach the real parser.


View raw message