On Tue, 2009-12-29 at 00:51 +0100, Stefano Bagnara wrote: > 2009/12/29 Robert Burrell Donkin <[email protected]>: > > On Sun, Dec 27, 2009 at 7:45 PM, Stefano Bagnara (JIRA) > > <[email protected]> wrote: > >> > >> [ > >> https://issues.apache.org/jira/browse/MIME4J-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > >> ] > >> > >> Stefano Bagnara resolved MIME4J-146. > >> ------------------------------------ > >> > >> Resolution: Fixed > >> > >> IMO this works as expected now. > >> All tests still pass. > >> If you have external code depending on the previous behaviour please > >> provide a testcase so that we can discuss the need of body to be unfolded > >> in the parser and not by RawField. > > > > i'm worried that this kind of change will break IMAP and/or jsieve in > > a way that's really hard to fix. this will really suck for james since > > we'll have to fork a known good version of mime4j. if someone could > > run the IMAP and JSieve build after any incompatible semantic change > > then at least there'd be a chance that the regression would be > > understood. > > Well, there was already changes wrt folding with MIME4J-141 so the > compatibility issue was already open.
I do not think so. Prior to MIME4J-146 only a copy of header body passed to the parser was unfolded. The original header body was never mutated. Oleg > Did you check imap/jsieve after > MIME4J-141 was changed? All of mime4j testcases passed before > MIME4J-141, after MIME4J-141 and after MIME4J-146. IMHO if external > code is "break in a way that's really hard to fix" then we should have > testcases for them. If you already have any pointer about your worries > this will help adding tests. > > As far as I can tell neither IMAP or Jsieve do care about > RawField.getBody and I'd say that if they even call getBody they > expect the unfolded data (that is how it is handled now). > > Stefano >
