You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Markus Wiederkehr (JIRA)" <se...@james.apache.org> on 2008/12/04 20:44:44 UTC
[jira] Created: (MIME4J-90) Consistent parsing of header field
names
Consistent parsing of header field names
----------------------------------------
Key: MIME4J-90
URL: https://issues.apache.org/jira/browse/MIME4J-90
Project: JAMES Mime4j
Issue Type: Bug
Affects Versions: 0.5
Reporter: Markus Wiederkehr
Priority: Minor
Fix For: 0.6
RFC 822 defines a field as:
field = field-name ":" [ field-body ] CRLF
field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
This implies that a field name must consist of at least one character and may not contain spaces or tabs; not even trailing ones.
Currently o.a.j.mime4j.parser.AbstractEntity#parseField accepts empty field names while o.a.j.mime4j.field.Field#parse accepts trailing spaces and tabs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jira] Commented: (MIME4J-90) Consistent parsing of header field names
Posted by Robert Burrell Donkin <ro...@gmail.com>.
basically, someone's going to have to go through all the usages of the
standalone field parsing foo in all the james libraries and explicitly
catch IllegalArgument exceptions. the rest of Mime4J throws checked
exceptions when parse problems are encountered so everytime that these
classes are used, developers are going to need to remember to catch
that exception. so, i think that at the very least, a strong warning
is required in the release notes.
if you don't like the checked exception, the other field subclasses
use getParseException. i don't love this design but it would be more
consistent if this convention was used to handle this use case.
- robert
On Thu, Jan 8, 2009 at 7:44 PM, Robert Burrell Donkin (JIRA)
<se...@james.apache.org> wrote:
>
> [ https://issues.apache.org/jira/browse/MIME4J-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12662087#action_12662087 ]
>
> Robert Burrell Donkin commented on MIME4J-90:
> ---------------------------------------------
>
> I don't seem to have done a very good job of explaining the issue.
>
> Using runtime exceptions make things difficult for correct protocol implementations. Typically, protocols have their own in-protocol error reporting systems. It is expected that exceptions will be checked so that developers can caught and correctly handle all expected known issues. Runtime exceptions are assumed to be fatal to the session and will typically result in the socket disconnecting (for security reasons, it's unwise to continue after a programming error).
>
> These are public classes and form a public API. The runtime was replaced by a checked exception to allow these classes to be safely used in protocol work in a standalone fashion. Reverting this design decision is a potentially dangerous decision since protocol implementations may be relying on the checked exception to correctly handle that condition. Upgrading will break any protocols which made this assumption.
>
> When breaking the contract of a public API, it is better to do this in a cleanly incompatible way. If this is not possible then it must be highlighted in the release notes.
>
>> Consistent parsing of header field names
>> ----------------------------------------
>>
>> Key: MIME4J-90
>> URL: https://issues.apache.org/jira/browse/MIME4J-90
>> Project: JAMES Mime4j
>> Issue Type: Bug
>> Affects Versions: 0.5
>> Reporter: Markus Wiederkehr
>> Priority: Minor
>> Fix For: 0.6
>>
>> Attachments: mime4j-fieldname.patch
>>
>>
>> RFC 822 defines a field as:
>> field = field-name ":" [ field-body ] CRLF
>> field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
>> This implies that a field name must consist of at least one character and may not contain spaces or tabs; not even trailing ones.
>> Currently o.a.j.mime4j.parser.AbstractEntity#parseField accepts empty field names while o.a.j.mime4j.field.Field#parse accepts trailing spaces and tabs.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jira] Commented: (MIME4J-90) Consistent parsing of header field names
Posted by Markus Wiederkehr <ma...@gmail.com>.
On Thu, Jan 8, 2009 at 10:23 PM, Markus Wiederkehr
<ma...@gmail.com> wrote:
> On Thu, Jan 8, 2009 at 8:44 PM, Robert Burrell Donkin (JIRA)
> <se...@james.apache.org> wrote:
>>
>> [ https://issues.apache.org/jira/browse/MIME4J-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12662087#action_12662087 ]
>>
>> Robert Burrell Donkin commented on MIME4J-90:
>> ---------------------------------------------
>>
>> I don't seem to have done a very good job of explaining the issue.
>>
>> Using runtime exceptions make things difficult for correct protocol implementations. Typically, protocols have their own in-protocol error reporting systems. It is expected that exceptions will be checked so that developers can caught and correctly handle all expected known issues. Runtime exceptions are assumed to be fatal to the session and will typically result in the socket disconnecting (for security reasons, it's unwise to continue after a programming error).
>
> Just to make sure I understand your concern correctly:
>
> You mean protocol implementations that invoke Field.parse() directly?
> Because if the protocol implementation uses a MimeStreamParser this
> cannot be an issue because AbstractEntity makes sure that the
> precondition of Field.parse() does not get violated.
>
>> These are public classes and form a public API. The runtime was replaced by a checked exception to allow these classes to be safely used in protocol work in a standalone fashion.
>
> Again, standalone as in "not driven by MimeStreamParser/ContentHandler"?
>
>>Reverting this design decision is a potentially dangerous decision since protocol implementations may be relying on the checked exception to correctly handle that condition. Upgrading will break any protocols which made this assumption.
>>
>> When breaking the contract of a public API, it is better to do this in a cleanly incompatible way. If this is not possible then it must be highlighted in the release notes.
>
> What would you think about keeping the checked exception in
> Field.parse() and adding a second method that throws an
> IllegalArgumentException instead? That second method could be used for
> creating or manipulating messages. Because for this use case the
> checked exception is really a PITA.
How about adding Field.parse(String fieldName, String fieldBody)?
Markus
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jira] Commented: (MIME4J-90) Consistent parsing of header field names
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On 1/8/09, Markus Wiederkehr <ma...@gmail.com> wrote:
> On Thu, Jan 8, 2009 at 11:05 PM, Robert Burrell Donkin
> <ro...@gmail.com> wrote:
>> On Thu, Jan 8, 2009 at 9:23 PM, Markus Wiederkehr
>> <ma...@gmail.com> wrote:
>>> On Thu, Jan 8, 2009 at 8:44 PM, Robert Burrell Donkin (JIRA)
>>> <se...@james.apache.org> wrote:
>>>>
>>>> [
>>>> https://issues.apache.org/jira/browse/MIME4J-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12662087#action_12662087
>>>> ]
>>>>
>>>> Robert Burrell Donkin commented on MIME4J-90:
>>>> ---------------------------------------------
>>>>
>>>> I don't seem to have done a very good job of explaining the issue.
>>>>
>>>> Using runtime exceptions make things difficult for correct protocol
>>>> implementations. Typically, protocols have their own in-protocol error
>>>> reporting systems. It is expected that exceptions will be checked so
>>>> that developers can caught and correctly handle all expected known
>>>> issues. Runtime exceptions are assumed to be fatal to the session and
>>>> will typically result in the socket disconnecting (for security reasons,
>>>> it's unwise to continue after a programming error).
>>>
>>> Just to make sure I understand your concern correctly:
>>>
>>> You mean protocol implementations that invoke Field.parse() directly?
>>> Because if the protocol implementation uses a MimeStreamParser this
>>> cannot be an issue because AbstractEntity makes sure that the
>>> precondition of Field.parse() does not get violated.
>>>
>>>> These are public classes and form a public API. The runtime was replaced
>>>> by a checked exception to allow these classes to be safely used in
>>>> protocol work in a standalone fashion.
>>>
>>> Again, standalone as in "not driven by MimeStreamParser/ContentHandler"?
>>
>> Yes
>>
>> Field.parse is public and so is part of the public API (though perhaps
>> this should be reconsidered)
>
> I think one way or another it has to stay that way. How else would it
> be possible to create a DOM from scratch?
By making the API internal to Mime4J. One way would be to use
packaging and (if possible) access to indicate this to users of the
library.
>
>>>>Reverting this design decision is a potentially dangerous decision since
>>>> protocol implementations may be relying on the checked exception to
>>>> correctly handle that condition. Upgrading will break any protocols
>>>> which made this assumption.
>>>>
>>>> When breaking the contract of a public API, it is better to do this in a
>>>> cleanly incompatible way. If this is not possible then it must be
>>>> highlighted in the release notes.
>>>
>>> What would you think about keeping the checked exception in
>>> Field.parse() and adding a second method that throws an
>>> IllegalArgumentException instead? That second method could be used for
>>> creating or manipulating messages. Because for this use case the
>>> checked exception is really a PITA.
>>
>> that was one of my suggestions, or alternatively just rename parse
>> without replacement so that it's clear the contract has change.
>>
>> but maybe it would be better to quickly reconsider the general design
>> in this area (i'm not a fan)
>
> Okay, for now I have attached a patch to MIME4J-90 that should resolve
> the issue. If we decide to overhaul the design it can be done in
> another JIRA..
I'll take a look this weekend
> What alternative do you have in mind?
>
>> if the general design is retained (i'd be happy enough to see it
>> revised without regard to compatibiltiy), these questions might be
>> worth thinking about:
>>
>> 1. should the parsing methods be part of the general public API?
>
> I believe yes because it's not feasible to write high-level setters
> for each and every possible header field. How would you set an
> X-header without some low-level operations, for example?
One strategy would be for the high level API to expose general, user
friendly methods which use the internal API
>> 2. if so, most Field subclasses store ParseException (in a property)
>> when something goes wrong. would it be worthwhile adopting this into
>> the general contract?
>
> Absolutely yes. The only problem seems to be that currently there is
> not one ParseException but five or so. These are generated by Javacc
> for each field type. We could chain these exceptions to a generic
> parse exception, of course..
IIRC the exceptions can be consolidated into a single hierarchy by
editing the JavaCC source. If this sounds worthwhile, I'll take a look
at this sometime soon (unless someone beats me to it)
- Robert
>
> Markus
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jira] Commented: (MIME4J-90) Consistent parsing of header field names
Posted by Markus Wiederkehr <ma...@gmail.com>.
On Thu, Jan 8, 2009 at 11:05 PM, Robert Burrell Donkin
<ro...@gmail.com> wrote:
> On Thu, Jan 8, 2009 at 9:23 PM, Markus Wiederkehr
> <ma...@gmail.com> wrote:
>> On Thu, Jan 8, 2009 at 8:44 PM, Robert Burrell Donkin (JIRA)
>> <se...@james.apache.org> wrote:
>>>
>>> [ https://issues.apache.org/jira/browse/MIME4J-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12662087#action_12662087 ]
>>>
>>> Robert Burrell Donkin commented on MIME4J-90:
>>> ---------------------------------------------
>>>
>>> I don't seem to have done a very good job of explaining the issue.
>>>
>>> Using runtime exceptions make things difficult for correct protocol implementations. Typically, protocols have their own in-protocol error reporting systems. It is expected that exceptions will be checked so that developers can caught and correctly handle all expected known issues. Runtime exceptions are assumed to be fatal to the session and will typically result in the socket disconnecting (for security reasons, it's unwise to continue after a programming error).
>>
>> Just to make sure I understand your concern correctly:
>>
>> You mean protocol implementations that invoke Field.parse() directly?
>> Because if the protocol implementation uses a MimeStreamParser this
>> cannot be an issue because AbstractEntity makes sure that the
>> precondition of Field.parse() does not get violated.
>>
>>> These are public classes and form a public API. The runtime was replaced by a checked exception to allow these classes to be safely used in protocol work in a standalone fashion.
>>
>> Again, standalone as in "not driven by MimeStreamParser/ContentHandler"?
>
> Yes
>
> Field.parse is public and so is part of the public API (though perhaps
> this should be reconsidered)
I think one way or another it has to stay that way. How else would it
be possible to create a DOM from scratch?
>>>Reverting this design decision is a potentially dangerous decision since protocol implementations may be relying on the checked exception to correctly handle that condition. Upgrading will break any protocols which made this assumption.
>>>
>>> When breaking the contract of a public API, it is better to do this in a cleanly incompatible way. If this is not possible then it must be highlighted in the release notes.
>>
>> What would you think about keeping the checked exception in
>> Field.parse() and adding a second method that throws an
>> IllegalArgumentException instead? That second method could be used for
>> creating or manipulating messages. Because for this use case the
>> checked exception is really a PITA.
>
> that was one of my suggestions, or alternatively just rename parse
> without replacement so that it's clear the contract has change.
>
> but maybe it would be better to quickly reconsider the general design
> in this area (i'm not a fan)
Okay, for now I have attached a patch to MIME4J-90 that should resolve
the issue. If we decide to overhaul the design it can be done in
another JIRA..
What alternative do you have in mind?
> if the general design is retained (i'd be happy enough to see it
> revised without regard to compatibiltiy), these questions might be
> worth thinking about:
>
> 1. should the parsing methods be part of the general public API?
I believe yes because it's not feasible to write high-level setters
for each and every possible header field. How would you set an
X-header without some low-level operations, for example?
> 2. if so, most Field subclasses store ParseException (in a property)
> when something goes wrong. would it be worthwhile adopting this into
> the general contract?
Absolutely yes. The only problem seems to be that currently there is
not one ParseException but five or so. These are generated by Javacc
for each field type. We could chain these exceptions to a generic
parse exception, of course..
Markus
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jira] Commented: (MIME4J-90) Consistent parsing of header field names
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Thu, Jan 8, 2009 at 9:23 PM, Markus Wiederkehr
<ma...@gmail.com> wrote:
> On Thu, Jan 8, 2009 at 8:44 PM, Robert Burrell Donkin (JIRA)
> <se...@james.apache.org> wrote:
>>
>> [ https://issues.apache.org/jira/browse/MIME4J-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12662087#action_12662087 ]
>>
>> Robert Burrell Donkin commented on MIME4J-90:
>> ---------------------------------------------
>>
>> I don't seem to have done a very good job of explaining the issue.
>>
>> Using runtime exceptions make things difficult for correct protocol implementations. Typically, protocols have their own in-protocol error reporting systems. It is expected that exceptions will be checked so that developers can caught and correctly handle all expected known issues. Runtime exceptions are assumed to be fatal to the session and will typically result in the socket disconnecting (for security reasons, it's unwise to continue after a programming error).
>
> Just to make sure I understand your concern correctly:
>
> You mean protocol implementations that invoke Field.parse() directly?
> Because if the protocol implementation uses a MimeStreamParser this
> cannot be an issue because AbstractEntity makes sure that the
> precondition of Field.parse() does not get violated.
>
>> These are public classes and form a public API. The runtime was replaced by a checked exception to allow these classes to be safely used in protocol work in a standalone fashion.
>
> Again, standalone as in "not driven by MimeStreamParser/ContentHandler"?
Yes
Field.parse is public and so is part of the public API (though perhaps
this should be reconsidered)
>>Reverting this design decision is a potentially dangerous decision since protocol implementations may be relying on the checked exception to correctly handle that condition. Upgrading will break any protocols which made this assumption.
>>
>> When breaking the contract of a public API, it is better to do this in a cleanly incompatible way. If this is not possible then it must be highlighted in the release notes.
>
> What would you think about keeping the checked exception in
> Field.parse() and adding a second method that throws an
> IllegalArgumentException instead? That second method could be used for
> creating or manipulating messages. Because for this use case the
> checked exception is really a PITA.
that was one of my suggestions, or alternatively just rename parse
without replacement so that it's clear the contract has change.
but maybe it would be better to quickly reconsider the general design
in this area (i'm not a fan)
if the general design is retained (i'd be happy enough to see it
revised without regard to compatibiltiy), these questions might be
worth thinking about:
1. should the parsing methods be part of the general public API?
2. if so, most Field subclasses store ParseException (in a property)
when something goes wrong. would it be worthwhile adopting this into
the general contract?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jira] Commented: (MIME4J-90) Consistent parsing of header field names
Posted by Markus Wiederkehr <ma...@gmail.com>.
On Thu, Jan 8, 2009 at 8:44 PM, Robert Burrell Donkin (JIRA)
<se...@james.apache.org> wrote:
>
> [ https://issues.apache.org/jira/browse/MIME4J-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12662087#action_12662087 ]
>
> Robert Burrell Donkin commented on MIME4J-90:
> ---------------------------------------------
>
> I don't seem to have done a very good job of explaining the issue.
>
> Using runtime exceptions make things difficult for correct protocol implementations. Typically, protocols have their own in-protocol error reporting systems. It is expected that exceptions will be checked so that developers can caught and correctly handle all expected known issues. Runtime exceptions are assumed to be fatal to the session and will typically result in the socket disconnecting (for security reasons, it's unwise to continue after a programming error).
Just to make sure I understand your concern correctly:
You mean protocol implementations that invoke Field.parse() directly?
Because if the protocol implementation uses a MimeStreamParser this
cannot be an issue because AbstractEntity makes sure that the
precondition of Field.parse() does not get violated.
> These are public classes and form a public API. The runtime was replaced by a checked exception to allow these classes to be safely used in protocol work in a standalone fashion.
Again, standalone as in "not driven by MimeStreamParser/ContentHandler"?
>Reverting this design decision is a potentially dangerous decision since protocol implementations may be relying on the checked exception to correctly handle that condition. Upgrading will break any protocols which made this assumption.
>
> When breaking the contract of a public API, it is better to do this in a cleanly incompatible way. If this is not possible then it must be highlighted in the release notes.
What would you think about keeping the checked exception in
Field.parse() and adding a second method that throws an
IllegalArgumentException instead? That second method could be used for
creating or manipulating messages. Because for this use case the
checked exception is really a PITA.
Markus
>
>> Consistent parsing of header field names
>> ----------------------------------------
>>
>> Key: MIME4J-90
>> URL: https://issues.apache.org/jira/browse/MIME4J-90
>> Project: JAMES Mime4j
>> Issue Type: Bug
>> Affects Versions: 0.5
>> Reporter: Markus Wiederkehr
>> Priority: Minor
>> Fix For: 0.6
>>
>> Attachments: mime4j-fieldname.patch
>>
>>
>> RFC 822 defines a field as:
>> field = field-name ":" [ field-body ] CRLF
>> field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
>> This implies that a field name must consist of at least one character and may not contain spaces or tabs; not even trailing ones.
>> Currently o.a.j.mime4j.parser.AbstractEntity#parseField accepts empty field names while o.a.j.mime4j.field.Field#parse accepts trailing spaces and tabs.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Updated: (MIME4J-90) Consistent parsing of header field
names
Posted by "Markus Wiederkehr (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Markus Wiederkehr updated MIME4J-90:
------------------------------------
Attachment: mime4j-parse-name-body.patch
> Consistent parsing of header field names
> ----------------------------------------
>
> Key: MIME4J-90
> URL: https://issues.apache.org/jira/browse/MIME4J-90
> Project: JAMES Mime4j
> Issue Type: Bug
> Affects Versions: 0.5
> Reporter: Markus Wiederkehr
> Priority: Minor
> Fix For: 0.6
>
> Attachments: mime4j-fieldname.patch, mime4j-parse-name-body.patch
>
>
> RFC 822 defines a field as:
> field = field-name ":" [ field-body ] CRLF
> field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
> This implies that a field name must consist of at least one character and may not contain spaces or tabs; not even trailing ones.
> Currently o.a.j.mime4j.parser.AbstractEntity#parseField accepts empty field names while o.a.j.mime4j.field.Field#parse accepts trailing spaces and tabs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-90) Consistent parsing of header field
names
Posted by "Robert Burrell Donkin (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654212#action_12654212 ]
Robert Burrell Donkin commented on MIME4J-90:
---------------------------------------------
I would prefer the a new name for this method.
At least, I would like to see strong warnings in the documentation and release notes.
I'm willing to dive in and help resolve this issue.
> Consistent parsing of header field names
> ----------------------------------------
>
> Key: MIME4J-90
> URL: https://issues.apache.org/jira/browse/MIME4J-90
> Project: JAMES Mime4j
> Issue Type: Bug
> Affects Versions: 0.5
> Reporter: Markus Wiederkehr
> Priority: Minor
> Fix For: 0.6
>
> Attachments: mime4j-fieldname.patch
>
>
> RFC 822 defines a field as:
> field = field-name ":" [ field-body ] CRLF
> field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
> This implies that a field name must consist of at least one character and may not contain spaces or tabs; not even trailing ones.
> Currently o.a.j.mime4j.parser.AbstractEntity#parseField accepts empty field names while o.a.j.mime4j.field.Field#parse accepts trailing spaces and tabs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Updated: (MIME4J-90) Consistent parsing of header field
names
Posted by "Markus Wiederkehr (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Markus Wiederkehr updated MIME4J-90:
------------------------------------
Attachment: (was: mime4j-parse-name-body.patch)
> Consistent parsing of header field names
> ----------------------------------------
>
> Key: MIME4J-90
> URL: https://issues.apache.org/jira/browse/MIME4J-90
> Project: JAMES Mime4j
> Issue Type: Bug
> Affects Versions: 0.5
> Reporter: Markus Wiederkehr
> Priority: Minor
> Fix For: 0.6
>
> Attachments: mime4j-fieldname.patch, mime4j-parse-name-body.patch
>
>
> RFC 822 defines a field as:
> field = field-name ":" [ field-body ] CRLF
> field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
> This implies that a field name must consist of at least one character and may not contain spaces or tabs; not even trailing ones.
> Currently o.a.j.mime4j.parser.AbstractEntity#parseField accepts empty field names while o.a.j.mime4j.field.Field#parse accepts trailing spaces and tabs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Closed: (MIME4J-90) Consistent parsing of header field names
Posted by "Markus Wiederkehr (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Markus Wiederkehr closed MIME4J-90.
-----------------------------------
Resolution: Fixed
> Consistent parsing of header field names
> ----------------------------------------
>
> Key: MIME4J-90
> URL: https://issues.apache.org/jira/browse/MIME4J-90
> Project: JAMES Mime4j
> Issue Type: Bug
> Affects Versions: 0.5
> Reporter: Markus Wiederkehr
> Priority: Minor
> Fix For: 0.6
>
> Attachments: mime4j-fieldname.patch, mime4j-parse-name-body.patch
>
>
> RFC 822 defines a field as:
> field = field-name ":" [ field-body ] CRLF
> field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
> This implies that a field name must consist of at least one character and may not contain spaces or tabs; not even trailing ones.
> Currently o.a.j.mime4j.parser.AbstractEntity#parseField accepts empty field names while o.a.j.mime4j.field.Field#parse accepts trailing spaces and tabs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-90) Consistent parsing of header field
names
Posted by "Oleg Kalnichevski (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12653454#action_12653454 ]
Oleg Kalnichevski commented on MIME4J-90:
-----------------------------------------
The patch looks good to me. I'll commit it if I hear no objections
Oleg
> Consistent parsing of header field names
> ----------------------------------------
>
> Key: MIME4J-90
> URL: https://issues.apache.org/jira/browse/MIME4J-90
> Project: JAMES Mime4j
> Issue Type: Bug
> Affects Versions: 0.5
> Reporter: Markus Wiederkehr
> Priority: Minor
> Fix For: 0.6
>
> Attachments: mime4j-fieldname.patch
>
>
> RFC 822 defines a field as:
> field = field-name ":" [ field-body ] CRLF
> field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
> This implies that a field name must consist of at least one character and may not contain spaces or tabs; not even trailing ones.
> Currently o.a.j.mime4j.parser.AbstractEntity#parseField accepts empty field names while o.a.j.mime4j.field.Field#parse accepts trailing spaces and tabs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-90) Consistent parsing of header field
names
Posted by "Robert Burrell Donkin (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12662087#action_12662087 ]
Robert Burrell Donkin commented on MIME4J-90:
---------------------------------------------
I don't seem to have done a very good job of explaining the issue.
Using runtime exceptions make things difficult for correct protocol implementations. Typically, protocols have their own in-protocol error reporting systems. It is expected that exceptions will be checked so that developers can caught and correctly handle all expected known issues. Runtime exceptions are assumed to be fatal to the session and will typically result in the socket disconnecting (for security reasons, it's unwise to continue after a programming error).
These are public classes and form a public API. The runtime was replaced by a checked exception to allow these classes to be safely used in protocol work in a standalone fashion. Reverting this design decision is a potentially dangerous decision since protocol implementations may be relying on the checked exception to correctly handle that condition. Upgrading will break any protocols which made this assumption.
When breaking the contract of a public API, it is better to do this in a cleanly incompatible way. If this is not possible then it must be highlighted in the release notes.
> Consistent parsing of header field names
> ----------------------------------------
>
> Key: MIME4J-90
> URL: https://issues.apache.org/jira/browse/MIME4J-90
> Project: JAMES Mime4j
> Issue Type: Bug
> Affects Versions: 0.5
> Reporter: Markus Wiederkehr
> Priority: Minor
> Fix For: 0.6
>
> Attachments: mime4j-fieldname.patch
>
>
> RFC 822 defines a field as:
> field = field-name ":" [ field-body ] CRLF
> field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
> This implies that a field name must consist of at least one character and may not contain spaces or tabs; not even trailing ones.
> Currently o.a.j.mime4j.parser.AbstractEntity#parseField accepts empty field names while o.a.j.mime4j.field.Field#parse accepts trailing spaces and tabs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Resolved: (MIME4J-90) Consistent parsing of header field
names
Posted by "Oleg Kalnichevski (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski resolved MIME4J-90.
-------------------------------------
Resolution: Fixed
Patch checked in
Oleg
> Consistent parsing of header field names
> ----------------------------------------
>
> Key: MIME4J-90
> URL: https://issues.apache.org/jira/browse/MIME4J-90
> Project: JAMES Mime4j
> Issue Type: Bug
> Affects Versions: 0.5
> Reporter: Markus Wiederkehr
> Priority: Minor
> Fix For: 0.6
>
> Attachments: mime4j-fieldname.patch
>
>
> RFC 822 defines a field as:
> field = field-name ":" [ field-body ] CRLF
> field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
> This implies that a field name must consist of at least one character and may not contain spaces or tabs; not even trailing ones.
> Currently o.a.j.mime4j.parser.AbstractEntity#parseField accepts empty field names while o.a.j.mime4j.field.Field#parse accepts trailing spaces and tabs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-90) Consistent parsing of header field
names
Posted by "Robert Burrell Donkin (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12662668#action_12662668 ]
Robert Burrell Donkin commented on MIME4J-90:
---------------------------------------------
I think the proposed API changes will address my concerns. Feel free to close this issue.
> Consistent parsing of header field names
> ----------------------------------------
>
> Key: MIME4J-90
> URL: https://issues.apache.org/jira/browse/MIME4J-90
> Project: JAMES Mime4j
> Issue Type: Bug
> Affects Versions: 0.5
> Reporter: Markus Wiederkehr
> Priority: Minor
> Fix For: 0.6
>
> Attachments: mime4j-fieldname.patch, mime4j-parse-name-body.patch
>
>
> RFC 822 defines a field as:
> field = field-name ":" [ field-body ] CRLF
> field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
> This implies that a field name must consist of at least one character and may not contain spaces or tabs; not even trailing ones.
> Currently o.a.j.mime4j.parser.AbstractEntity#parseField accepts empty field names while o.a.j.mime4j.field.Field#parse accepts trailing spaces and tabs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Updated: (MIME4J-90) Consistent parsing of header field
names
Posted by "Markus Wiederkehr (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Markus Wiederkehr updated MIME4J-90:
------------------------------------
Attachment: mime4j-fieldname.patch
This patch should resolve the issue.
As a consequence it also changes the MimeException thrown by Field#parse back to IllegalArgumentException (see also MIME4J-73). This is safe now because Field#parse never gets called with an illegal argument from a ContentHandler. AbstractEntity#parseField already drops invalid header fields.
> Consistent parsing of header field names
> ----------------------------------------
>
> Key: MIME4J-90
> URL: https://issues.apache.org/jira/browse/MIME4J-90
> Project: JAMES Mime4j
> Issue Type: Bug
> Affects Versions: 0.5
> Reporter: Markus Wiederkehr
> Priority: Minor
> Fix For: 0.6
>
> Attachments: mime4j-fieldname.patch
>
>
> RFC 822 defines a field as:
> field = field-name ":" [ field-body ] CRLF
> field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
> This implies that a field name must consist of at least one character and may not contain spaces or tabs; not even trailing ones.
> Currently o.a.j.mime4j.parser.AbstractEntity#parseField accepts empty field names while o.a.j.mime4j.field.Field#parse accepts trailing spaces and tabs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Updated: (MIME4J-90) Consistent parsing of header field
names
Posted by "Markus Wiederkehr (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Markus Wiederkehr updated MIME4J-90:
------------------------------------
Attachment: mime4j-parse-name-body.patch
Here is another patch that would work for me. It keeps the MimeException in Field.parse(String raw) and adds another method Field.parse(String name, String value) that does not throw an exception.
Please review.
> Consistent parsing of header field names
> ----------------------------------------
>
> Key: MIME4J-90
> URL: https://issues.apache.org/jira/browse/MIME4J-90
> Project: JAMES Mime4j
> Issue Type: Bug
> Affects Versions: 0.5
> Reporter: Markus Wiederkehr
> Priority: Minor
> Fix For: 0.6
>
> Attachments: mime4j-fieldname.patch, mime4j-parse-name-body.patch
>
>
> RFC 822 defines a field as:
> field = field-name ":" [ field-body ] CRLF
> field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
> This implies that a field name must consist of at least one character and may not contain spaces or tabs; not even trailing ones.
> Currently o.a.j.mime4j.parser.AbstractEntity#parseField accepts empty field names while o.a.j.mime4j.field.Field#parse accepts trailing spaces and tabs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Reopened: (MIME4J-90) Consistent parsing of header field
names
Posted by "Robert Burrell Donkin (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Burrell Donkin reopened MIME4J-90:
-----------------------------------------
Field.parse is a public method. As such, it's not just used by Mime4J. I'm concerned about the potential impact on users of this method.
Switching from throwing a MimeException to a runtime requires users of that method to revise their exception handling strategies. Switching to less lenient parsing only increases this risk.
> Consistent parsing of header field names
> ----------------------------------------
>
> Key: MIME4J-90
> URL: https://issues.apache.org/jira/browse/MIME4J-90
> Project: JAMES Mime4j
> Issue Type: Bug
> Affects Versions: 0.5
> Reporter: Markus Wiederkehr
> Priority: Minor
> Fix For: 0.6
>
> Attachments: mime4j-fieldname.patch
>
>
> RFC 822 defines a field as:
> field = field-name ":" [ field-body ] CRLF
> field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
> This implies that a field name must consist of at least one character and may not contain spaces or tabs; not even trailing ones.
> Currently o.a.j.mime4j.parser.AbstractEntity#parseField accepts empty field names while o.a.j.mime4j.field.Field#parse accepts trailing spaces and tabs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-90) Consistent parsing of header field
names
Posted by "Markus Wiederkehr (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654547#action_12654547 ]
Markus Wiederkehr commented on MIME4J-90:
-----------------------------------------
Robert, please note that this method has always been throwing an IllegalArgumentException up to and including release 0.4. We changed it to a MimeException for 0.5 in MIME4J-73.
At the time I was not aware of the fact that o.a.j.mime4j.parser.AbstractEntity#parseField already parses the header fields before it passes them to a ContentHandler. It splits the header field into key and value and checks if the key conforms to RFC 822. If this is not the case the header field gets dropped entirely.
So the change to a MimeException was based on a false assumption. Changing it back to the way it was should not cause big problems for the users of this method.
> Consistent parsing of header field names
> ----------------------------------------
>
> Key: MIME4J-90
> URL: https://issues.apache.org/jira/browse/MIME4J-90
> Project: JAMES Mime4j
> Issue Type: Bug
> Affects Versions: 0.5
> Reporter: Markus Wiederkehr
> Priority: Minor
> Fix For: 0.6
>
> Attachments: mime4j-fieldname.patch
>
>
> RFC 822 defines a field as:
> field = field-name ":" [ field-body ] CRLF
> field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
> This implies that a field name must consist of at least one character and may not contain spaces or tabs; not even trailing ones.
> Currently o.a.j.mime4j.parser.AbstractEntity#parseField accepts empty field names while o.a.j.mime4j.field.Field#parse accepts trailing spaces and tabs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org