james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Markus Wiederkehr" <markus.wiederk...@gmail.com>
Subject Re: [jira] Commented: (MIME4J-90) Consistent parsing of header field names
Date Thu, 08 Jan 2009 21:23:45 GMT
On Thu, Jan 8, 2009 at 8:44 PM, Robert Burrell Donkin (JIRA)
<server-dev@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


Mime
View raw message