Выяснение, почему этот веб-сервис не работает

Question

Я имею дело с веб-службой одного из моих государственных учреждений для электронных документов. WSDL можно найти здесь: https://maullin.sii.cl/DTEWS/CrSeed.jws?WSDL

Я попытался вызвать метод getSeed() (который является единственным релевантным) в http://www.soapclient.com/soaptest.html, чтобы увидеть, работает ли он, и действительно это так.

Я создал сервисную библиотеку WCF , чтобы проверить это, и я получил следующую ошибку:

System.ServiceModel.FaultException: 'org.xml.sax.SAXParseException: содержимое не разрешено в прологе.'

Быстрый поиск в Интернете показывает, что многие пользователи испытывают эту проблему при попытке реализовать этот конкретный веб-сервис, и все они, похоже, указывают на некоторые обновления Windows. Все указывают на другой, который нужно удалить, и именно так некоторые из них решили эту проблему.

Я не верю, что это вопрос конкретного обновления Windows, возможно, есть что-то еще. Поэтому вместо этого я попытался создать Приложение службы WCF и разместить веб-службу в IIS, чтобы проверить, не является ли это какой-то проблемой отладки.

В консольном проекте я пытаюсь вызвать метод getSeed(), но в итоге он возвращает null строку вместо SAXParseException.

Так в чем здесь дело? Мне кажется, это довольно просто:

 1. Add the service reference
 2. Create a new instance of CrSeedClient class
 3. Call getSeed() method.

Почему у меня возникают все эти проблемы с этим конкретным веб-сервисом?

Кстати, я использую Net Framework 4.7.2 / Windows 10 / Visual Studio 2017

Может кто-нибудь проверить это, пожалуйста? Спасибо.

---

РЕДАКТИРОВАТЬ!: Прочитать мой собственный ответ ...

Answer 1

Хорошо, в конце концов, это был кошмар. Это включало сначала отключение патча безопасности, сделанного Microsoft. Вот подробности:

https://support.microsoft.com/en-us/help/3155464/ms16-065-description-of-the-tls-ssl-protocol-information-disclosure-vu

Я сделал это программно:

    AppContext.SetSwitch("TestSwitch.LocalAppContext.DisableCaching", true); 
    AppContext.SetSwitch("Switch.System.Net.DontEnableSchSendAuxRecord", true);

Таким образом, я мог бы пройти мимо org.xml.sax.SAXParseException, который был ответом, сделанным WebServer. Даже когда я изменил необработанное сообщение, используя пользовательский конвертер сообщений, похоже, что это WCF или, возможно, даже ОС записывала несколько байтов или изменяла окончательное сообщение SOAP на лету. Отключение этого исправления безопасности на лету предотвратило это.

Теперь, благодаря пользовательскому кодировщику сообщений, я увидел, что веб-служба наконец-то вернула правильное сообщение, но WCF неправильно его проанализировала. После нескольких часов тестирования я понял:

Оригинальный ответ:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<getSeedResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<getSeedReturn xsi:type="xsd:string">
<?xml version="1.0" encoding="UTF-8"?><SII:RESPUESTA xmlns:SII="http://www.sii.cl/XMLSchema"><SII:RESP_BODY><SEMILLA>013052590000</SEMILLA></SII:RESP_BODY><SII:RESP_HDR><ESTADO>00</ESTADO></SII:RESP_HDR></SII:RESPUESTA>
</getSeedReturn>
</getSeedResponse>
</soapenv:Body>
</soapenv:Envelope>

Удалив префикс ns1 повсюду (включая xmlns:ns1="http://DefaultNamespace"), я мог бы наконец получить правильный разбор.

После исправления:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<getSeedResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<getSeedReturn xsi:type="xsd:string">
<?xml version="1.0" encoding="UTF-8"?><SII:RESPUESTA xmlns:SII="http://www.sii.cl/XMLSchema"><SII:RESP_BODY><SEMILLA>013052590000</SEMILLA></SII:RESP_BODY><SII:RESP_HDR><ESTADO>00</ESTADO></SII:RESP_HDR></SII:RESPUESTA>
</getSeedReturn>
</getSeedResponse>
</soapenv:Body>
</soapenv:Envelope>

Я до сих пор не понимаю ни патча безопасности, ни того, почему WCF не удается проанализировать сообщение с префиксом NS1.

Если бы кто-нибудь осмелился взглянуть на это, я был бы очень рад, потому что я думаю, что эти решения немного хакерские и, честно говоря, я понимаю, почему люди предпочли бы использовать java вместо WCF.