[ https://issues.apache.org/jira/browse/CXF-7530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Freeman Fang updated CXF-7530: ------------------------------ Description: In rfc2046[1], the MIME message should be {code} 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. {code} So the {code} multipart-body := [preamble CRLF] preamble := discard-text discard-text := *(*text CRLF) ; May be ignored or discarded. {code} 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 {code} Content-Type: multipart/related; type="text/xml"; boundary="uuid:71ba280a-0d00-4272-aa25-5de22cbe8a6b"; start="<root.mess...@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.mess...@cxf.apache.org>\CR\LF \CR\LF <?xml version='1.0' encoding='UTF-8'?><soapenv:Envelo {code} The expected one should be {code} Content-Type: multipart/related; type="text/xml"; boundary="uuid:71ba280a-0d00-4272-aa25-5de22cbe8a6b"; start="<root.mess...@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.mess...@cxf.apache.org>\CR\LF \CR\LF <?xml version='1.0' encoding='UTF-8'?><soapenv:Envelo {code} 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 was: In rfc2046[1], the MIME message should be {code} 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. {code} So the {code} multipart-body := [preamble CRLF] preamble := discard-text {code} [1]https://www.ietf.org/rfc/rfc2046.txt > AttachmentSerializer miss a CRLF before the multipart-body per spec rfc2046 > --------------------------------------------------------------------------- > > Key: CXF-7530 > URL: https://issues.apache.org/jira/browse/CXF-7530 > Project: CXF > Issue Type: Bug > Reporter: Freeman Fang > Assignee: Freeman Fang > > In rfc2046[1], the MIME message should be > {code} > 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. > {code} > So the > {code} > multipart-body := [preamble CRLF] > preamble := discard-text > discard-text := *(*text CRLF) > ; May be ignored or discarded. > {code} > 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 > {code} > Content-Type: multipart/related; type="text/xml"; > boundary="uuid:71ba280a-0d00-4272-aa25-5de22cbe8a6b"; > start="<root.mess...@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.mess...@cxf.apache.org>\CR\LF > \CR\LF > <?xml version='1.0' encoding='UTF-8'?><soapenv:Envelo > {code} > The expected one should be > {code} > Content-Type: multipart/related; type="text/xml"; > boundary="uuid:71ba280a-0d00-4272-aa25-5de22cbe8a6b"; > start="<root.mess...@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.mess...@cxf.apache.org>\CR\LF > \CR\LF > <?xml version='1.0' encoding='UTF-8'?><soapenv:Envelo > {code} > 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 -- This message was sent by Atlassian JIRA (v6.4.14#64029)