Hi Vivek,
thank you.
Yes "start" is optional, I found it in
http://www.ietf.org/rfc/rfc2387.txt.
The .NET Client is definitive configured for MTOM.
I can't imagine where the problem lies.
Here is the whole response (without the binary):
********************************************************************************************
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=6156A549140745D2AD142A1F826387A4; Path=/geoengine
Content-Type: Multipart/Related; type="application/xop+xml";
boundary="----=_Part_2_18504142.1143467055109"; start-info="text/xml"
Content-Length: 59571
Date: Mon, 27 Mar 2006 13:44:15 GMT
------=_Part_2_18504142.1143467055109
Content-Type: application/xop+xml; type="text/xml"; charset=utf-8
<?xml version="1.0" ?>
<soapenv:Envelope xmlns:soapenv="
http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="
http://www.w3.org/2001/XMLSchema"
xmlns:ns1="
http://www.ddd.de/mtom/data"
xmlns:ns2="
http://www.w3.org/2005/05/xmlmime">
<soapenv:Header>
</soapenv:Header>
<soapenv:Body>
<ns1:GetGeoComponentResponse>
<ns1:success>true</ns1:success>
<ns1:geoComponent xmime:contentType="application/pdf">
<xop:Include xmlns:xop="
http://www.w3.org/2004/08/xop/include"
href="cid:dddf4909-f6ad-4be5-8f2e-b2f3351ebf54_at_www.xyz.de"></xop:Include>
</ns1:geoComponent>
</ns1:GetGeoComponentResponse>
</soapenv:Body>
</soapenv:Envelope>
------=_Part_2_18504142.1143467055109
Content-Type: application/octet-stream
Content-ID: <dddf4909-f6ad-4be5-8f2e-b2f3351ebf54_at_www.xyz.de>
Content-transfer-encoding: binary
PDF Binary datas EOF
------=_Part_2_18504142.1143467055109--
********************************************************************************************
Florian
Vivek Pandey wrote:
> start is optional on Multipart/Related - if present it tells which
> MIME part is the root part and if absent the first MIME part in the
> Multipart/Related structure is the root part. Since JAXWS reponse has
> no start parameter and the first part is the root so .NET should be
> taking it alright.
>
> From the error it looks that .NET client is not expecting an Mtom
> encoded response can you check .net client configuration to see if its
> configured for Mtom Encoded endpoint?
>
> -vivek.
>
> Florian Rengers wrote:
>
>>
>> Hi,
>>
>> I wrote a Service based on the Java-Technology JAX-WS which provides
>> documents MTOM encoded and I wrote a consumer-client in c#.NET.
>>
>> On client-side I get an exception during deserialisation the
>> response-message:
>>
>> System.InvalidOperationException
>> Client found response content type of
>> 'Multipart/Related; type=\"application/xop+xml\";
>> boundary=\"----=_Part_0_24598445.1143476873406\";
>> start-info=\"text/xml\"',
>> but expected 'text/xml'.
>>
>> I sniffed the in- and outcomming messages. Here is the JAX-WS
>> response(shorted):
>>
>> ***************************************************************************
>>
>> Server: Apache-Coyote/1.1
>> Set-Cookie: JSESSIONID=6156A549140745D2AD142A1F826387A4;
>> Path=/geoengine
>> Content-Type: Multipart/Related; type="application/xop+xml";
>> boundary="----=_Part_2_18504142.1143467055109"; start-info="text/xml"
>> Content-Length: 59571
>> Date: Mon, 27 Mar 2006 13:44:15 GMT
>>
>> ------=_Part_2_18504142.1143467055109
>> Content-Type: application/xop+xml; type="text/xml"; charset=utf-8
>>
>> <XML-RESPONSE>
>> ------=_Part_2_18504142.1143467055109
>> Content-Type: application/octet-stream
>> Content-ID: <dddf4909-f6ad-4be5-8f2e-b2f3351ebf54_at_www.grit.de
>> <mailto:dddf4909-f6ad-4be5-8f2e-b2f3351ebf54_at_www.grit.de>>
>> Content-transfer-encoding: binary
>>
>> [BINARY DATA]
>>
>> ------=_Part_2_18504142.1143467055109--
>> ***************************************************************************
>>
>>
>> The only significant difference between .NET request and JAX-WS
>> response is that the .NET request has an additional property "start"
>> in its content-header which links to the message-part and "charset"
>> is set to "utf-8".
>>
>> Could this be the reason for the fault?
>>
>> Best Regards
>>
>> Florian
>>
>>
>