Mailing-List: contact mime4j-dev-help@james.apache.org; run by ezmlm
Precedence: bulk
Reply-To: mime4j-dev@james.apache.org
Received-SPF: pass (athena.apache.org: domain of apache@bago.org designates
 209.85.216.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <20110419145336.9F6552388962@eris.apache.org>
References: <20110419145336.9F6552388962@eris.apache.org>
From: Stefano Bagnara <apache@bago.org>
Date: Tue, 19 Apr 2011 17:02:52 +0200
Message-ID: <BANLkTi=5hYtsqqHqyoUnntXjoTFov4FWQg@mail.gmail.com>
Subject: Re: svn commit: r1095104 - in
 /james/mime4j/trunk/core/src/main/java/org/apache/james/mime4j:
 io/MimeBoundaryInputStream.java stream/Event.java stream/MimeEntity.java
To: mime4j-dev@james.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

2011/4/19  <olegk@apache.org>:
> Author: olegk
> Date: Tue Apr 19 14:53:36 2011
> New Revision: 1095104
>
> URL: http://svn.apache.org/viewvc?rev=3D1095104&view=3Drev
> Log:
> Moved presence of whitespace chars in boundary check from MimeBoundaryInp=
utStream's constructor to MimeEntity where this protocol violation can be h=
anlded leniently depending on the parsing mode
[..]
> + =A0 =A0/** Indicates that while space characters have been found in the=
 boundary */
> + =A0 =A0public static final Event WHITESPACE_IN_BOUNDARY
> + =A0 =A0 =A0 =A0=3D new Event("Boundary may not contain CR or LF");

This does not seem intuitive. CR or LF are not what is commonly known
as "white space".
CR and LF cannot be present inside a boundary, even in lenient mode.
Instead a single space (0x20) is allowed in the boundary (IIRC).

I don't think we need to "monitor" the presence of a real white space.

Stefano