Florian Rengers wrote:
> 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.
>
From the client side error message it seems that the .net client is
expecting "text/xml" content-type instead of "Multipart/Related" which
is what an Mtom encoded message will have in the Http content-type.
See[1]. I dont know .Net enough to tell you what might be wrong there
but looking at jaxws response I can say its a valid Mtom message.
-vivek.
[1]
http://www.w3.org/TR/soap12-mtom/#mime-serialization
> 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
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jax-ws.dev.java.net
> For additional commands, e-mail: users-help_at_jax-ws.dev.java.net
>
--
Vivek Pandey
Web Services Standards and Technologies
Sun Microsystems Inc.