Клиент WCF обращается к Java WS, исключение: тип содержимого application / xop + xml; type = application / soap + xml ответного сообщения

У меня проблемы с подключением к Java WS. Я использую привязку "wsHttpBinding" с клиентскими сертификатами для аутентификации, кодировка сообщений установлена ​​"Текст", .NET framework 4.0. Сторона сервера - это Java, и я не могу ее контролировать. Соединение проксируется через Fiddler (именно так я вижу запросы по сети, гораздо удобнее, чем отслеживание "System.Net").

Я получаю следующее исключение:

Тип контента application / xop + xml; type = "application / soap + xml" ответного сообщения не соответствует типу содержимого привязки (application / soap + xml; charset = utf-8).

Если я изменю кодировку сообщения на «Mtom», то исключение изменится:

Тип контента application / xop + xml; type = "application / soap + xml" ответного сообщения не соответствует типу содержимого привязки (multipart / related; type = "application / xop + xml").

Сервер принимает для запроса кодировки сообщений «Text» и «Mtom», и ответ всегда один и тот же. Это необработанный ответ, который я получаю от сервера:

HTTP/1.1 200 OK
X-Backside-Transport: OK OK
Connection: Keep-Alive
X-Powered-By: Servlet/3.0
SOAPAction: ""
Content-Type: application/xop+xml; type="application/soap+xml"
Content-Language: en-US
Date: Thu, 25 Jul 2013 13:05:09 GMT
Content-Length: 628

<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope  ...   </env:Envelope>

Из всех документов, которые я читал, возвращаемый ответ находится где-то между обычным сообщением SOAP и сообщением MTOM. Я говорю это, потому что каждый пример, который я видел, говорит о том, что запрос и ответ MTOM используют MIME в качестве конверта для связи: обычное сообщение SOAP заключено в пакет XOP, а затем это сообщение XOP заключено в MIME. Даже в рекомендации W3C для пакетов XOP используется MIME: W3C: упаковка, оптимизированная для двоичного кода XML. Выдержка из этой ссылки:

Content-Type: Multipart/Related;boundary=...

Если я попытаюсь вызвать веб-службу с помощью инструмента «soapUI» (написанного на Java, доступного на «www.soapui.org»), вызов службы будет успешно выполнен, и ответ будет проанализирован без каких-либо проблем.

К вашему сведению, это кросс-сообщение от MSDN WCF forum., но ответов пока нет.

Любая идея приветствуется, заранее спасибо,

Алекс


person alemarko    schedule 26.07.2013    source источник
comment
Я столкнулся с той же проблемой. Создание настраиваемой привязки и установка messageVersion = Soap12 у меня не сработали. Одно различие, которое я вижу, заключается в том, что мой вызов веб-службы - https, но этот пост, похоже, предназначен для http.   -  person Anjani Kumar Agrawal    schedule 27.01.2017
comment
Вы нашли решение? У меня такая же проблема. Но конфигурация привязки, предложенная в первом ответе, недействительна для web.config.   -  person Cheshire Cat    schedule 16.05.2017
comment
HTTP против HTTPS не имеет значения: это всего лишь транспортная деталь. Проблема в форматировании сообщения. Проблема, с которой я столкнулся, заключалась в том, что правительственный орган использовал какой-то сервер Java (с использованием стека IBM WebSphere), и их стек создавал несоответствующие сообщения. В моем случае было два варианта: 1.) использовать SoapUI в качестве внешнего приложения, которое загрузит сообщение, а затем проанализирует XML на C # 2.) отредактировать необработанный XML, который приходит по сети, и изменить XML сообщения в соответствии со стандартами - ›это Кстати все было сделано на C #.   -  person alemarko    schedule 18.05.2017


Ответы (2)


Я также использую CXF и имею клиент C #. Попробуйте изменить настройку привязки, заменив textMessageEncoding на mtomMessageEncoding. Что-то вроде этого:

<binding name="yourSoapBinding">
    <mtomMessageEncoding messageVersion="Soap12"/>
    <httpTransport />
</binding>
person duleshi    schedule 04.08.2015

Попробуйте установить кодировку сообщения в конфигурации привязки на messageEncoding="Mtom" и basicHTTPBinding вместо wsHTTP ...

Надеюсь, поможет!

person user2759562    schedule 08.09.2013