You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by cdcienses <ju...@gmail.com> on 2008/07/08 14:34:04 UTC

RE: URL-Encoded ContentIDs cause interop problems with Axis2

I had the same error... the problem was , at least in my case, when I was
creating the datahandler at the service to send it to the client.

I was creating the datahandler with a non existing file (due to an error in
the name). I was confused because I expected a different error message for
that kind of failure (for example a "file not exists" or something like
that)

So you have to check that the file exists (or the permissions are rigth to
get that file...)

--

Julio Francisco Vicente Sánchez



CMoesel wrote:
> 
> 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:Christopher_Moesel@avid.com] 
> Sent: Tuesday, April 24, 2007 12:26 PM
> To: cxf-user@incubator.apache.org
> 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:24762dfc-7400-4d08-b5ec-01ea18e97a49@avid.com
> 
> 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: <ro...@cxf.apache.org> 
> 
> 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
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/URL-Encoded-ContentIDs-cause-interop-problems-with-Axis2-tp10164676p18338171.html
Sent from the cxf-user mailing list archive at Nabble.com.