Re: [reSIProcate-users] Mixed Content misses CRLF
Thanks a lot.
How about PlainContents and OctetContents, is CRLF needed at the end of
this Content?
Regards,
Frank Y.
-----Original Message-----
From: Adam Roach [mailto:adam@xxxxxxxxxxx]
Sent: Monday, September 15, 2008 11:03 AM
To: Yuan, Frank
Cc: resiprocate-users
Subject: Re: [reSIProcate-users] Mixed Content misses CRLF
The trailing CRLF isn't necessary, and my reading of the spec is that a
CRLF where you have added it is actively discouraged.
The syntax comes from RFC 2046. A multipart body is defined as:
multipart-body := [preamble CRLF]
dash-boundary transport-padding CRLF
body-part *encapsulation
close-delimiter transport-padding
[CRLF epilogue]
The element you're looking at is the "close-delimiter", which is defined
as:
close-delimiter := delimiter "--"
Note the lack of any CRLF in the "close-delimiter" definition.
The normative behavior on "transport-padding" begins: "Composers MUST
NOT generate non-zero length transport padding." So, legally, this is a
zero-length field on generation.
Everything after that is optional (note the brackets). If you're going
to include an epilogue section (which is discouraged by RFC 2046), you
prepend it with a CRLF. However, if there is no epilogue, a CRLF isn't
called for.
/a
On 9/15/08 10:24 AM, Yuan, Frank wrote:
>
> Hi,
>
> std::ostream&
>
> MultipartMixedContents::encodeParsed(std::ostream& str) const
>
> {
>
>
........................................................................
.........................
>
> str << Symbols::CRLF << boundary << Symbols::DASHDASH;
>
> return str;
>
> }
>
> I think the end of boundary should need CRFL as
>
> str << Symbols::CRLF << boundary << Symbols::DASHDASH<< Symbols::CRLF;
>
> Regards,
>
> Frank Y.
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> resiprocate-users mailing list
> resiprocate-users@xxxxxxxxxxxxxxx
> List Archive: http://list.resiprocate.org/archive/resiprocate-users/