I found the spot in the CXF code where this gets encoded... and after some research, it appears that the cid should be encoded, except that '@' is actually a valid character (don't encode).
I've modified the code locally and am testing it out. If successful, I will submit a patch. -Chris -----Original Message----- From: Christopher Moesel [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 24, 2007 12:26 PM To: [email protected] Subject: URL-Encoded ContentIDs cause interop problems with Axis2 Hello List, I've encountered an interoperability issue using an Axis2 client to access an MTOM-enabled CXF service. The issue only occurs when the service sends a streaming binary attachment to the client. Here is the error I receive from my Axis 2 client: java.lang.RuntimeException: org.apache.axiom.om.OMException: Referenced Attachment not found in the MIME Message. ContentID:[EMAIL PROTECTED] Using TCPMon, I see that the ContentID in the message is: Content-ID: <24762dfc-7400-4d08-b5ec-01ea18e97a49%40avid.com> I suspect that the Axis2 client URL-decodes the ContentID that is referenced in the SOAP message, so %40 becomes @. But when it searches for the matching attachment, it is probably not URL-decoding the ContentID in the attachments, so it doesn't find a match. Although this is probably an Axis2 bug, I wonder why CXF URL-encodes the ContentID in the first place? It appears it only does this for the streaming binary attachments. The first part of the message, containing the root message does NOT URL-encode the ContentID: Content-ID: <[EMAIL PROTECTED]> It seems that for consistency and interoperability's sake, the ContentID should either always be URL-encoded or never be URL-encoded. In this case, based on Axis2's behavior, I'd vote that it is never URL-encoded. I'll take a look to see if I can find where this is happening in the code. -Chris
