cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Freeman Fang (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CXF-7530) AttachmentSerializer miss a CRLF before the multipart-body per spec rfc2046
Date Mon, 16 Oct 2017 03:22:00 GMT

     [ 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.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
{code}

The expected one should be 
{code}
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
{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.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
> {code}
> The expected one should be 
> {code}
> 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
> {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)

Mime
View raw message