Apologies, I skipped the part where it says "converting %hh hex-escaped characters to their ASCII equivalents".
Indeed this is a client issue (third party). 2009/12/11 Max Ferrari <[email protected]>: > 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%[email protected]" corresponds to > > Message-ID: <foo4%[email protected]> > > What happens in CXF 2.2 also after the fix to issue CXF-596 is that > the "cid" URL is converted to a completely unescaped Content-ID in the > MIME header, so we have for example: > > cid:5726d366-df25-4945-9f3b-3003a2ae8a70-3@http%3A%2F%2Fcxf.apache.org%2F > > becomes > > Content-ID: <5726d366-df25-4945-9f3b-3003a2ae8a7...@http://cxf.apache.org/> > > whereas as per the RFC example one would expect > > Content-ID: > <5726d366-df25-4945-9f3b-3003a2ae8a7...@http%3a%2f%2fcxf.apache.org%2f> > > This breaks interoperability with other consumers (servers) at the moment. > > > 2009/12/11 Max Ferrari <[email protected]>: >> I've just found this: >> https://issues.apache.org/jira/browse/CXF-596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel >> >> The fix applies to CXF 2.0, we're using CXF 2.2 and still experience >> something very similar; possibly a Camel issue? We're using camel-cxf >> 1.6.2. >> Can't find anything on Camel's Jira, crossposting to camel-users. >> >> 2009/12/10 Max Ferrari <[email protected]>: >>> 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 >>> >> > > > > -- > Max > -- Max
