[OT] Re: Anyone competing with Zend?
amb-plug at bradfords.org
Mon Sep 26 22:40:38 MDT 2005
[This is a resend]
Thus said Lonnie Olson on Mon, 26 Sep 2005 14:38:09 MDT:
> Actually No. There is a newline before the next boundary, that is why
> it comes on the next line. There is not an *extra* newline, however
> that is not required.
I'm sorry, but I don't believe that RFC 1521 and RFC 2049 agree with
you... An *extra* newline is required.
Note that the encapsulation boundary must occur at the beginning of a
line, i.e., following a CRLF, and that the initial CRLF is considered
to be attached to the encapsulation boundary rather than part of the
preceding part. The boundary must be followed immediately either by
another CRLF and the header fields for the next part, or by two
CRLFs, in which case there are no header fields for the next part
(and it is therefore assumed to be of Content-Type text/plain).
NOTE: The CRLF preceding the encapsulation line is conceptually
attached to the boundary so that it is possible to have a part
that does not end with a CRLF (line break). Body parts that must
be considered to end with line breaks, therefore, must have two
CRLFs preceding the encapsulation line, the first of which is part
of the preceding body part, and the second of which is part of the
(7) The BNF for the multipart media type has been
rearranged to make it clear that the CRLF preceeding
the boundary marker is actually part of the marker
itself rather than the preceeding body part.
So, the CRLF that precedes the boundary is actually part of the boundary
itself, which means that if you only have one newline then it will be
stripped by an RFC compliant MIME parser. Indeed, none of the examples
in RFC 2049 show a boundary that immediately follow the last line of
text without an additional newline.
> The messages Wade, and myself send *are* formatted correctly. The
> problem is only with the way Mail.app *displays* the messages.
Sounds like the MIME parser is compliant while the MIME writer is not.
Hence, the fact that the PLUG trailer appears to merge right into the
last line of Wade's text.
GnuPG ID 0xA63888C9 (D2DA 68C9 BB2B 26B4 8204 2219 A43E F450 A638 88C9)
10:40pm up 98 days, 7:18, 3 users, load average: 1.06, 1.48, 1.40
More information about the PLUG