cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michel Decima (JIRA)" <>
Subject [jira] Created: (CXF-2669) MTOM producer - different content-id in XOP:Include and MIME part for the same attachment
Date Fri, 12 Feb 2010 15:54:27 GMT
MTOM producer - different content-id in XOP:Include and MIME part for the same attachment

                 Key: CXF-2669
             Project: CXF
          Issue Type: Improvement
          Components: Core
    Affects Versions: 2.2.6
            Reporter: Michel Decima

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=""

(please notice escaped URI in the cid)

- instead, the actual Content-Id in the multipart POST part is unescaped:
Content-ID: <5726d366-df25-4945-9f3b-3003a2ae8a70-4@>

>From RFC2111 ( :

   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:

63   public static String createContentID(String ns) throws UnsupportedEncodingException {
64       // tend to change
65       String cid = "";
67       String name = ATT_UUID + "-" + String.valueOf(++counter);
68       if (ns != null && (ns.length() > 0)) {
69           try {
70               URI uri = new URI(ns);
71               String host = uri.toURL().getHost();
72               cid = host;
73           } catch (URISyntaxException e) {
74               cid = ns;
75           } catch (MalformedURLException e) {
76               cid = ns;
77           }
78       }
79       return URLEncoder.encode(name, "UTF-8") + "@" + URLEncoder.encode(cid, "UTF-8");
80   }

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 
"" (full absolute URL, not the host part of it), and 
then the result of the function will contain hex-escaped characters, like 

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 "", 
the result will be :

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

To be more consistent, the function should use only the host part "" 
if namespace is null/empty. In other words, calling createContentId() explicitely 
with empty namespace and "" 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

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message