james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Burrell Donkin" <robertburrelldon...@gmail.com>
Subject Re: Bug in ContentTypeParser.jj?
Date Tue, 18 Mar 2008 22:24:30 GMT
On Tue, Mar 18, 2008 at 9:54 PM, Antony Bowesman <adb@teamware.com> wrote:

> Hi Robert,
> > IIRC there are some test mails which use boundary string containing only
> > digits. if you are willing to contribute a unit test or two that
> > demonstrates the problem, it'd help a lot. please use
> > https://issues.apache.org/jira/browse/MIME4J
> Done.  I ticked the wrong box for the ASF licence, but could not edit it
> to
> grant licence to ASF, but the test case can be included if needed.


> It's related to general digit only parameter values, not just boundary
> strings
> but the test case shows a digit only example boundary string.


> > hmmm...
> >
> > fiddling with the tokenisation seems more risky. so the first sounds
> like
> > the better solution to me. (hopefully people will jump in if this seems
> > wrong to them...)
> I agree, RFC allows all digits, so there's probably nothing wrong in
> including it.

the main pull parser parses all digit boundaries fine. having taken a look,
Message seems to me to do far too much of it's own parsing. this parsing
seems pretty buggy and also unnecessary: BodyDescriptor contains parsed

IMHO the right way to fix this problem is to rewrite Message so that the
information is obtained from the meta-data provided by the main parser. but
Message isn't really something i've played around with before and i'm out of
time this evening. if you'd like to had a go at revising the implementation,
it should be reasonable easy. otherwise, unless anyone jumps in with a
better implementations strategy, i should be able to take a look at this

- robert

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message