mime4j: question about EOLConvertingInputStream

[Greg Fichtenholtz <gr...@yahoo.com>]

Hello,
I have a question about the usage of EOLConvertingInputStream.
Background:
I have found that messages constructed like this:
String requestMsg =
 "--AaB03x\n" +
  "Content-Type: text/plain\n" +
  "Content-ID: part1\n" +
  "\n" +
  "This is part 1 of the mime package\n" +
  "--AaB03x\n" +
  "Content-Type: application/xml\n" +
  "Content-ID: part2\n" +
  "\n" +
  "<ThisIsPart2 />";
With Content-Type header value being "multipart/related; boundary=AaB03x"
do not get parsed correctly. This appears to be a (IMHO, poor) design choice, 
as I see this statement in javadoc for MimeStreamParser
 * All lines must end with CRLF (<code>\r\n</code>). If you are unsure of 
 * the line endings in your stream you should wrap it in a 
 * EOLConvertingInputStream instance.
 
and sure enough when I wrap my input with EOLConvertingInputStream 
everything works fine. 
However, this immediately raises a question:
won't EOLConvertingInputStream essentially corrupt a stream that 
just happens to have binary data?
E.g. what if my request message just happened to have another part with
Content-Transfer-Encoding: binary with binary data that happens to have 
a bunch of random \n. Won't the use of EOLConvertingInputStream corrupt 
my data?
If the answer is yes,  How do I make the parser treat line separators 
leniently  without data corruption? (i.e. I want \n to work just as well as \r\n)
Thanks in advance
Greg


      

---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org

Re: mime4j: question about EOLConvertingInputStream

[Stefano Bagnara <ap...@bago.org>]

Greg Fichtenholtz ha scritto:
> Hello,
> I have a question about the usage of EOLConvertingInputStream.
> Background:
> I have found that messages constructed like this:
> String requestMsg =
>  "--AaB03x\n" +
>   "Content-Type: text/plain\n" +
>   "Content-ID: part1\n" +
>   "\n" +
>   "This is part 1 of the mime package\n" +
>   "--AaB03x\n" +
>   "Content-Type: application/xml\n" +
>   "Content-ID: part2\n" +
>   "\n" +
>   "<ThisIsPart2 />";
> With Content-Type header value being "multipart/related; boundary=AaB03x"
> do not get parsed correctly. This appears to be a (IMHO, poor) design choice, 
> as I see this statement in javadoc for MimeStreamParser
>  * All lines must end with CRLF (<code>\r\n</code>). If you are unsure of 
>  * the line endings in your stream you should wrap it in a 
>  * EOLConvertingInputStream instance.
>  
> and sure enough when I wrap my input with EOLConvertingInputStream 
> everything works fine. 
> However, this immediately raises a question:
> won't EOLConvertingInputStream essentially corrupt a stream that 
> just happens to have binary data?
> E.g. what if my request message just happened to have another part with
> Content-Transfer-Encoding: binary with binary data that happens to have 
> a bunch of random \n. Won't the use of EOLConvertingInputStream corrupt 
> my data?
> If the answer is yes,  How do I make the parser treat line separators 
> leniently  without data corruption? (i.e. I want \n to work just as well as \r\n)
> Thanks in advance
> Greg

Are you using mime4j 0.3 ?
In this case the answer is yes, and there is no way to deal with binary 
content. mime4j 0.3 was mainly used for email content and unless you 
support "MAIL BODY=BINARY" (no server I know) there is no way to send 
CRLF that are not end of lines. The "8bit" encoding is not binary but 
998 lenght binary sequences separated by CRLF and not including CRLF.

If you instead are using mime4j 0.4 (a nightly or a custom build or some 
release candidate) then by default it is lenient about newlines and you 
don't need the EOLConvertingInputStream.

Mime4J 0.4 is on the way to be release. We'll probably release it in a week.

Steefano

---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org