You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mime4j-dev@james.apache.org by "Stefano Bagnara (JIRA)" <mi...@james.apache.org> on 2009/12/27 20:45:29 UTC
[jira] Resolved: (MIME4J-146) [possible backward incompatibility]
Make sure "body" is always unfolded, "raw" is always folded, both in
RawField and ParsedFields.
[ 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.
> [possible backward incompatibility] Make sure "body" is always unfolded, "raw" is always folded, both in RawField and ParsedFields.
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: MIME4J-146
> URL: https://issues.apache.org/jira/browse/MIME4J-146
> Project: JAMES Mime4j
> Issue Type: Task
> Affects Versions: 0.6
> Reporter: Stefano Bagnara
> Assignee: Stefano Bagnara
> Priority: Critical
> Fix For: 0.7
>
>
> In the current code it's not consistent how we deal with folding and unfolding.
> The most used way (in the current code) is to have "raw" as the original, folded, version of the header, while body includes the unfolded/decoded version of the header.
> RawField.getBody should be changed to "unfold" the field.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Resolved: (MIME4J-146) [possible backward incompatibility]
Make sure "body" is always unfolded, "raw" is always folded, both in RawField
and ParsedFields.
Posted by Stefano Bagnara <ap...@bago.org>.
2009/12/29 Oleg Kalnichevski <ol...@apache.org>:
> On Tue, 2009-12-29 at 11:31 +0100, Stefano Bagnara wrote:
>> 2009/12/29 Oleg Kalnichevski <ol...@apache.org>:
>> > On Tue, 2009-12-29 at 00:51 +0100, Stefano Bagnara wrote:
>> >> 2009/12/29 Robert Burrell Donkin <ro...@gmail.com>:
>> >> > 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.
>>
>> What I mean is that DelegatingFieldParse.parse changed the behaviour
>> with MIME4J-141 (previously it wasn't unfolding body, after it
>> unfolded body). Whenever we change anything we can break things. IMO
>> we should care about improving the current mime4j and if this means
>> breaking some old code then the old code will need to be fixed/updated
>> too. IMO jSieve doesn't care less of this stuff, while IMAP uses this
>> only in message searching, and I would be that returning an unfolded
>> body (like we do after MIME4J-146) FIXES a bug in searching strings in
>> folded headers.
>>
>> BTW discussing whether this change introduce backward incompatibility
>> or not is a waste of time. Changing things introduce backward
>> incompatbilities. IMO the new behaviour is better than the old, and at
>> least the new behaviour show consistency in what people is expected to
>> get when they call Field.getBody (before mime4j-146 sometimes you got
>> unfolded body, sometimes folded body.. for the same original header).
>>
>
> Stefano, this is not about appointing the blame. However, just to get
> things straight, prior to MIME4J-141 DelegatingFieldParse would simply
> choke on folded values, plain and simple. So, MIME4J-141 fixed a
> breakage without changing any existing behavior.
This depends on what is the intended usage of Parse. If we agree that
"raw" is a folded byte sequence, and "body" is always an unfolded
string then we should not have considered the previous behaviour a
bug.
We desperately need to add meaning to our methods. Let's define what
is a field body (IMO an unfolded/decoded string representing the
header) and make mime4j consistent in its usage. In my own view,
MIME4J-141 added a workaround for a bug in RawField, as the parser
(always IMO) was not expected to receive newlines in field values.
>> If you think the change is bad I'll revert it. If you think there is a
>> better solution, write about it.
>>
>
> I am personally in favor of the change and would like to keep it. I
> would even go as far as suggesting the field body value be trimmed as
> well. We just need to make sure Robert's concerns are addressed. If the
> only way to do so is by reverting the change, I am afraid this is what
> we will have to do.
I've investigated both jSieve and IMAP (and you can see I also tried
to start tracking downstream users) and I really don't understand
Robert's concerns. As I wrote previously this change, if anything,
*FIXES* a possible issue in IMAP search. I guess he simply had no time
to have a better look to the real patch and he's worried I'm randomly
changing code ;-)
I understand we agree that mime4j has consistency issues, interface
issues, code organization issues. Let's start to fix some of them. If
we talk so much about MIME4J-146 (nothing revolutionary, just a
bugfix) then we won't move anywhere and we won't fix anything. If you
*fear* my code ability I can work in branches, but I think history
proved that branches are not good for this stuff.
I bet that if I simply didn't mark the issue with "backward
incompatibility" and instead I committed silently we wouldn't even be
discussing ;-) ... 0.4, 0.5 and 0.6 introduced much bigger changes
with less noise ;-)
Stefano
Re: [jira] Resolved: (MIME4J-146) [possible backward
incompatibility] Make sure "body" is always unfolded, "raw" is always
folded, both in RawField and ParsedFields.
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Tue, 2009-12-29 at 11:31 +0100, Stefano Bagnara wrote:
> 2009/12/29 Oleg Kalnichevski <ol...@apache.org>:
> > On Tue, 2009-12-29 at 00:51 +0100, Stefano Bagnara wrote:
> >> 2009/12/29 Robert Burrell Donkin <ro...@gmail.com>:
> >> > 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.
>
> What I mean is that DelegatingFieldParse.parse changed the behaviour
> with MIME4J-141 (previously it wasn't unfolding body, after it
> unfolded body). Whenever we change anything we can break things. IMO
> we should care about improving the current mime4j and if this means
> breaking some old code then the old code will need to be fixed/updated
> too. IMO jSieve doesn't care less of this stuff, while IMAP uses this
> only in message searching, and I would be that returning an unfolded
> body (like we do after MIME4J-146) FIXES a bug in searching strings in
> folded headers.
>
> BTW discussing whether this change introduce backward incompatibility
> or not is a waste of time. Changing things introduce backward
> incompatbilities. IMO the new behaviour is better than the old, and at
> least the new behaviour show consistency in what people is expected to
> get when they call Field.getBody (before mime4j-146 sometimes you got
> unfolded body, sometimes folded body.. for the same original header).
>
Stefano, this is not about appointing the blame. However, just to get
things straight, prior to MIME4J-141 DelegatingFieldParse would simply
choke on folded values, plain and simple. So, MIME4J-141 fixed a
breakage without changing any existing behavior.
> If you think the change is bad I'll revert it. If you think there is a
> better solution, write about it.
>
I am personally in favor of the change and would like to keep it. I
would even go as far as suggesting the field body value be trimmed as
well. We just need to make sure Robert's concerns are addressed. If the
only way to do so is by reverting the change, I am afraid this is what
we will have to do.
Cheers
Oleg
> Stefano
>
Re: [jira] Resolved: (MIME4J-146) [possible backward incompatibility]
Make sure "body" is always unfolded, "raw" is always folded, both in RawField
and ParsedFields.
Posted by Stefano Bagnara <ap...@bago.org>.
2009/12/29 Oleg Kalnichevski <ol...@apache.org>:
> On Tue, 2009-12-29 at 00:51 +0100, Stefano Bagnara wrote:
>> 2009/12/29 Robert Burrell Donkin <ro...@gmail.com>:
>> > 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.
What I mean is that DelegatingFieldParse.parse changed the behaviour
with MIME4J-141 (previously it wasn't unfolding body, after it
unfolded body). Whenever we change anything we can break things. IMO
we should care about improving the current mime4j and if this means
breaking some old code then the old code will need to be fixed/updated
too. IMO jSieve doesn't care less of this stuff, while IMAP uses this
only in message searching, and I would be that returning an unfolded
body (like we do after MIME4J-146) FIXES a bug in searching strings in
folded headers.
BTW discussing whether this change introduce backward incompatibility
or not is a waste of time. Changing things introduce backward
incompatbilities. IMO the new behaviour is better than the old, and at
least the new behaviour show consistency in what people is expected to
get when they call Field.getBody (before mime4j-146 sometimes you got
unfolded body, sometimes folded body.. for the same original header).
If you think the change is bad I'll revert it. If you think there is a
better solution, write about it.
Stefano
Re: [jira] Resolved: (MIME4J-146) [possible backward
incompatibility] Make sure "body" is always unfolded, "raw" is always
folded, both in RawField and ParsedFields.
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Tue, 2009-12-29 at 00:51 +0100, Stefano Bagnara wrote:
> 2009/12/29 Robert Burrell Donkin <ro...@gmail.com>:
> > On Sun, Dec 27, 2009 at 7:45 PM, Stefano Bagnara (JIRA)
> > <mi...@james.apache.org> 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
>
Re: [jira] Resolved: (MIME4J-146) [possible backward incompatibility]
Make sure "body" is always unfolded, "raw" is always folded, both in RawField
and ParsedFields.
Posted by Stefano Bagnara <ap...@bago.org>.
2009/12/29 Robert Burrell Donkin <ro...@gmail.com>:
> On Sun, Dec 27, 2009 at 7:45 PM, Stefano Bagnara (JIRA)
> <mi...@james.apache.org> 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. 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
Re: [jira] Resolved: (MIME4J-146) [possible backward incompatibility]
Make sure "body" is always unfolded, "raw" is always folded, both in RawField
and ParsedFields.
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sun, Dec 27, 2009 at 7:45 PM, Stefano Bagnara (JIRA)
<mi...@james.apache.org> 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.
- robert