I'd be ok changing the default if it would be more interopable. Please file a JIRA with a patch. :-)
Dan On Wed February 10 2010 11:15:46 am Michel Decima wrote: > 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. -- Daniel Kulp [email protected] http://www.dankulp.com/blog
