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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
