Stefano, Thank you for your reply. Yes we are using mime4j 0.3. We will try to switch to 0.4 whenever it comes out. In the meantime we'll just tell our users that lines have to be CRLF terminated in the payload according to RFC822 Thanks again Greg
----- Original Message ---- From: Stefano Bagnara <[EMAIL PROTECTED]> To: James Users List <[email protected]> Sent: Friday, August 15, 2008 10:51:21 AM Subject: Re: mime4j: question about EOLConvertingInputStream 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
