Hello, We are facing exactly the same issue here : third-party server unable to handle attachment sent by MTOM producer because of escaped cid:
Max Ferrari wrote: > >> following to an (apparently) valid request from our CXF client, the >> server replies with a SOAP fault: >> <SOAP-ENV:Fault><faultcode>Sender</faultcode><faultstring>cannot get >> mime part</faultstring></SOAP-ENV:Fault> >> >> I've analyzed the http conversation and I observe that: >> >> - 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) > Thanks to Max, I understand that the behaviour of CXF according to RFC2111, and the third-party server should handle hex-escaped cid values. However, the server vendor can't provide a solution, because the external library they use to process attachments does not handle hex-escaped values, and they can't upgrade easily to another library. So I browsed the CXF source tree to see how the cid and Contend-ID are generated. In class org.apache.cxf.attachment.AttachmentUtil, we have: 63 public static String createContentID(String ns) throws UnsupportedEncodingException { 64 // tend to change 65 String cid = "http://cxf.apache.org/";; 66 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 "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-3003a2ae8a7...@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://foo.bar.com";, the result will be : [email protected] and this string value does not contains hex-escaped characters. So I searched a way to specify a custom namespace to createContentID from my client code generated from WSDL by $CXF_HOME/bin/wsld2java, but I did not found how to do it. Is it possible ? (if yes, problem solved). Then, I took a closer look to the createContentId() function, and I think that its behaviour is not very coherent : if the namespace (ns) is not null, only the host part is used, but if it is null, the full URL "http://cxf.apache.org/"; with "http://"; prefix is used. 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 : String s1 = AttachmentUtil.createContentID( "" ) ; String s2 = AttachmentUtil.createContentID( "http://cxf.apache.org/"; ) ; assert s1.substring( s1.indexOf('@')).equals( s2.substring( s2.indexOf('@')) ); Currently, the assertion above fails, and obviously we just have to change the default cid value line 65 : 65 String cid = "cxf.apache.org" ; // was "http://cxf.apache.org/"; 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 our current server. What do you think ? Best Regards, -- Michel Decima. -- View this message in context: http://old.nabble.com/MTOM-producer---different-content-id-in-XOP%3AInclude-and-MIME-part-for--the-same-attachment--tp26729418p27533761.html Sent from the cxf-user mailing list archive at Nabble.com.
