You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Freeman Fang (JIRA)" <ji...@apache.org> on 2017/10/16 06:35:00 UTC

[jira] [Resolved] (CXF-7530) AttachmentSerializer miss a CRLF before the multipart-body per spec rfc2046

     [ https://issues.apache.org/jira/browse/CXF-7530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Freeman Fang resolved CXF-7530.
-------------------------------
       Resolution: Fixed
    Fix Version/s: 3.2.1
                   3.1.14
                   3.0.16

> 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
>             Fix For: 3.0.16, 3.1.14, 3.2.1
>
>
> 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="<ro...@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: <ro...@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="<ro...@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: <ro...@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)