You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Christopher Moesel <Ch...@avid.com> on 2007/04/24 18:26:17 UTC
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
RE: URL-Encoded ContentIDs cause interop problems with Axis2
Posted by cdcienses <ju...@gmail.com>.
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.
RE: URL-Encoded ContentIDs cause interop problems with Axis2
Posted by Christopher Moesel <Ch...@avid.com>.
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