On Tue, Feb 24, 2009 at 2:46 PM, Robert Burrell Donkin (JIRA) <[email protected]> wrote: > > [ > https://issues.apache.org/jira/browse/MIME4J-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12676270#action_12676270 > ] > > Robert Burrell Donkin commented on MIME4J-118: > ---------------------------------------------- > > I suspect that there may be longer term issues with this general approach but > i think we should accept that the current proposal is good enough for this > release. release early, release often.
+1 on the release part but I need a few days to clean up that patch. > I think that the best way to approach is to preserve the original document > together with boundary meta-data. In other words, that a 'Content-Type' > header starts at byte 99 in the document rather than trying to slice up the > document and re-assemble from lots of small byte buffers. But this is related > to other issues which should wait until after this release so I think we > should patch and look to ship. We can cross that bridge when we come to it but I don't particularly like the idea of having to open a file, seek to position 99 and read 50 bytes just to obtain the raw value of a Content-Type field, for example. Also please mind that Field instances may be shared between multiple messages and they can be created from a constructor or factory without an original document to back them up. And last but not least with nested encodings there is no meaningful offset into a file.. Markus >> MIME stream parser handles non-ASCII fields incorrectly >> ------------------------------------------------------- >> >> Key: MIME4J-118 >> URL: https://issues.apache.org/jira/browse/MIME4J-118 >> Project: JAMES Mime4j >> Issue Type: Bug >> Reporter: Oleg Kalnichevski >> Assignee: Oleg Kalnichevski >> Fix For: 0.6 >> >> Attachments: mime4j-118-bytesequence-draft.patch, >> mime4j-118-field.patch, mimej4-118.patch >> >> >> Presently MIME stream parser handles non-ASCII fields incorrectly. Binary >> field content gets converted to its textual representation too early in the >> parsing process using simple byte to char cast. The decision about >> appropriate char encoding should be left up to individual ContentHandler >> implementations. >> Oleg > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
