Hi List, we are using in a camel route a cxf producer (client) enpoint with MTOM enabled. The consumer (server) at the moment is a 'black box' sitting in our customer's environment.
The issue: 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) - instead, the actual Content-Id in the multipart POST part is unescaped: Content-ID: <5726d366-df25-4945-9f3b-3003a2ae8a7...@http://cxf.apache.org/> The point is that, if I replay using Fiddler the same request, by replacing the escaped part of the cid with an unescaped one, so that XOP and MIME content IDs are exactly the same: <xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include"; href="cid:5726d366-df25-4945-9f3b-3003a2ae8a70-3@http://cxf.apache.org/"/> then the server replies with a 200 OK. Now, I suspect that the escaped cid in the SOAP part is perfectly legal and that it's the consumer implementation's fault not matching it correctly to the MIME part. However I'd need some clear normative references to discuss this to the customer. Actually at http://www.w3.org/TR/2004/CR-xop10-20040826/#mime_xop_packages I read: Part metadata is reflected in MIME header fields. Specifically, the URI used in the value of an href attribute information item on a xop:Include element information item contains a URI that uses the 'cid:' scheme (see [RFC 2392]), so the corresponding MIME part MUST have a Content-ID header field (see [RFC 2387] with a corresponding field-value. Some comments from CXF developers would be greatly appreciated. Thanks Max
