Uploaded image for project: 'CXF'
  1. CXF
  2. CXF-2669

MTOM producer - different content-id in XOP:Include and MIME part for the same attachment

    XMLWordPrintableJSON

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.2.6
    • Fix Version/s: 2.2.7
    • Component/s: Core
    • Labels:
      None
    • Estimated Complexity:
      Novice

      Description

      Some third-party server can't receive MTOM attachment sent by CXF clients
      because "cid" URL and Content-ID are different.

      • In the SOAP part of the request the attachments are included as:
        <xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include"
        href="cid:5726d366-df25-4945-9f3b-3003a2ae8a70-3@http%3A%2F%2Fcxf.apache.org%2F"/>

      (please notice escaped cxf.apache.org URI in the cid)

      • instead, the actual Content-Id in the multipart POST part is unescaped:
        Content-ID: <5726d366-df25-4945-9f3b-3003a2ae8a70-4@http://cxf.apache.org/>

      From RFC2111 (http://www.ietf.org/rfc/rfc2111.txt) :

      A "cid" URL is converted to the corresponding Content-ID message
      header [MIME] by removing the "cid:" prefix, converting %hh hex-
      escaped characters to their ASCII equivalents and enclosing the
      remaining parts with an angle bracket pair, "<" and ">". For
      example, "mid:foo4%25foo1@..." corresponds to

      Message-ID: <foo4%foo1@...>

      According to this RFC, the "cid" URL and Content-ID are perfectly legal.

      However, the behaviour of the function createContentID() from class
      org.apache.cxf.attachment.AttachmentUtil is not very consistent:

      The full content-id is the result of concatenation of a random part (name) and a
      suffix part (cid) after encoding with URLencoder.

      If the argument ns is null or empty, the suffix defaults to
      "http://cxf.apache.org" (full absolute URL, not the host part of it), and
      then the result of the function will contain hex-escaped characters, like
      this:

      5726d366-df25-4945-9f3b-3003a2ae8a70-3@http%3A%2F%2Fcxf.apache.org%2F

      If the argument ns is not null and not empty, then ns is used to build an
      URL, and the host part of this URL will be used as suffix value. Thus, if we
      call this function with a specific namespace, for example "http://cxf.apache.org",
      the result will be :

      5726d366-df25-4945-9f3b-3003a2ae8a70-3@cxf.apache.org

      and this string value does not contains hex-escaped characters.

      To be more consistent, the function should use only the host part "cxf.apache.org"
      if namespace is null/empty. In other words, calling createContentId() explicitely
      with empty namespace and "http://cxf.apache.org/" should give the same value for
      the suffix part (after character @).

      Since this modification affects only the default suffix value, the algorithm
      stays the same, and hex-escaped characters are processed as expected. But, as
      a side effect, the generated contentID will be compatible with current third-party
      server.

        Attachments

        1. patch.txt
          0.7 kB
          Michel Decima

          Activity

            People

            • Assignee:
              dkulp Daniel Kulp
              Reporter:
              decimami Michel Decima
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: