Major Description
In rfc2046[1], the MIME message should be
Appendix A -- Collected Grammar This appendix contains the complete BNF grammar for all the syntax specified by this document. By itself, however, this grammar is incomplete. It refers by name to several syntax rules that are defined by RFC 822. Rather than reproduce those definitions here, and risk unintentional differences between the two, this document simply refers the reader to RFC 822 for the remaining definitions. Wherever a term is undefined, it refers to the RFC 822 definition. boundary := 0*69<bchars> bcharsnospace bchars := bcharsnospace / " " bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" / "_" / "," / "-" / "." / "/" / ":" / "=" / "?" body-part := <"message" as defined in RFC 822, with all header fields optional, not starting with the specified dash-boundary, and with the delimiter not occurring anywhere in the body part. Note that the semantics of a part differ from the semantics of a message, as described in the text.> close-delimiter := delimiter "--" dash-boundary := "--" boundary ; boundary taken from the value of ; boundary parameter of the ; Content-Type field. delimiter := CRLF dash-boundary discard-text := *(*text CRLF) ; May be ignored or discarded. encapsulation := delimiter transport-padding CRLF body-part epilogue := discard-text multipart-body := [preamble CRLF] dash-boundary transport-padding CRLF body-part *encapsulation Freed & Borenstein Standards Track [Page 43] RFC 2046 Media Types November 1996 close-delimiter transport-padding [CRLF epilogue] preamble := discard-text transport-padding := *LWSP-char ; Composers MUST NOT generate ; non-zero length transport ; padding, but receivers MUST ; be able to handle padding ; added by message transports.
So the
multipart-body := [preamble CRLF]
preamble := discard-text
discard-text := *(*text CRLF)
; May be ignored or discarded.
So per the spec, there should be two CRLF before the first attachment uuid, so one for the termination of discard-text (*(*text CRLF)) and one for the [preamble CRLF]
So intead of the message like
Content-Type: multipart/related; type="text/xml"; boundary="uuid:71ba280a-0d00-4272-aa25-5de22cbe8a6b"; start="<root.message@cxf.apache.org>"; start-info="text/xml"\CR\LF --uuid:71ba280a-0d00-4272-aa25-5de22cbe8a6b\CR\LF Content-Type: text/xml; charset=UTF-8; type="text/xml"\CR\LF Content-Transfer-Encoding: binary\CR\LF Content-ID: <root.message@cxf.apache.org>\CR\LF \CR\LF <?xml version='1.0' encoding='UTF-8'?><soapenv:Envelo
The expected one should be
Content-Type: multipart/related; type="text/xml"; boundary="uuid:71ba280a-0d00-4272-aa25-5de22cbe8a6b"; start="<root.message@cxf.apache.org>"; start-info="text/xml"\CR\LF \CR\LF --uuid:71ba280a-0d00-4272-aa25-5de22cbe8a6b\CR\LF Content-Type: text/xml; charset=UTF-8; type="text/xml"\CR\LF Content-Transfer-Encoding: binary\CR\LF Content-ID: <root.message@cxf.apache.org>\CR\LF \CR\LF <?xml version='1.0' encoding='UTF-8'?><soapenv:Envelo
Current code will cause some soap stack which strictly follow the spec rfc2046 failed to read MTOM message sent out by CXF
[1]https://www.ietf.org/rfc/rfc2046.txt