[
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="<[email protected]>"; 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: <[email protected]>\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="<[email protected]>"; 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: <[email protected]>\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="<[email protected]>"; 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: <[email protected]>\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="<[email protected]>"; 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: <[email protected]>\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)
