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 Justin Robinson <dk...@fluidnotions.com> on 2013/09/27 15:19:26 UTC

apache-jdkim-0.2 HeadlessParsing - how is this supposed to work?

The nature of my integration requires headers and body of the message to
come from 2 separate byte streams.

The headers get parsed without issue (only thing is I've stepped through
the code and not come across canonicalization processing for header or body
- is such supposed to be manual?)

If I combine the 2 streams for header and body, the body is always empty.

eg:

 ByteArrayInputStream headerAndBodyInputStream = new ByteArrayInputStream(
headerStream.toByteArray());

 headerAndBodyInputStream.read("\r\n".getBytes());

 headerAndBodyInputStream.read(bodyStream.toByteArray());

 headerAndBodyInputStream.read("\r\n".getBytes());

The header gets parsed and the body is not, in fact the length of the
InputStream is indicates the body never exists in it at all
org.apache.james.mime4j.stream.MimeTokenStream.doParse(InputStream,
EntityState)

I wrote a test case using the contents of the 2 streams hard coded into a
string, I even used the wrong line endings to make sure this was not the
issue, but EOLConvertingInputStream, correctly converted them, the header
and body where both parsed without issue.

Then I wrote another test case that parses the 2 streams from there
separate files, combines them and prints the result to file before parsing
in into the signer, once again the body is dropped.

When I compare the combined stream output file to that copied into the hard
coded string in a diff app, they are identical.

So my conclusion was to use  HeadlessParsing, I first parse the headers,
then the body using cfg.setHeadlessParsing("multipart/alternative");

The javadoc says little, just it must not be null, but I know from stepping
through that the content-type is set from this value.

The body is still empty.

*Any suggestions?*

I could write to file then read from file, but for performance reasons I'd
rather avoid HDD operations.