Клиент службы WCF: текст типа контента /html; charset = utf-8 ответного сообщения не соответствует типу содержимого привязки

Ответ 1

Попробуйте перейти на http://localhost/ScraperService.svc в веб-браузере на сервере, на котором размещена служба, с использованием тех же учетных данных Windows, которые обычно выполняются клиентом.

Я предполагаю, что IIS отображает сообщение об ошибке html некоторого описания вместо того, чтобы возвращать xml, как ожидалось.

Это также может произойти, если у вас есть HTTP-прокси-сервер, который выполняет фильтрацию через Интернет. Мой опыт с ContentKeeper заключается в том, что он перехватывает любой трафик http/https и блокирует его как "Неуправляемый контент" - все, что мы получаем, это сообщение об ошибке html. Чтобы этого избежать, вы можете добавить правила исключения прокси-сервера в Internet Explorer, чтобы прокси-сервер не перехватил трафик на ваш сайт:

Панель управления > Свойства обозревателя > Соединения > Настройки локальной сети > Дополнительно > Настройки прокси-сервера

Ответ 2

Отклик HTML на веб-сервере обычно указывает, что вместо ответа от службы WCF была показана страница с ошибкой. Мое первое предложение состояло в том, чтобы проверить, что пользователь, которому вы управляете клиентом WCF, имеет доступ к ресурсу.

Ответ 3

У меня была аналогичная проблема. Я разрешил это, изменив

<basicHttpBinding>

to

<basicHttpsBinding>

а также изменил мой URL-адрес, чтобы использовать https://вместо http://.

Также в <endpoint> node, измените

binding="basicHttpBinding" 

to

binding="basicHttpsBinding"

Это сработало.

Ответ 4

что происходит, вы пытаетесь получить доступ к службе с помощью wsHttpBind, которые по умолчанию используют защищенные зашифрованные сообщения (защищенные сообщения). С другой стороны, netTcpBind использует защищенные зашифрованные каналы. (Обеспеченный транспорт)... НО basicHttpBind, не требует никакой безопасности вообще и может получить доступ к анонимному

SO. на стороне сервера, добавьте\Измените это в свою конфигурацию.

<bindings>
    <wsHttpBinding>
     <binding name="wsbind"> 
         <security mode="Message">
             <transport clientCredentialType="Windows" proxyCredentialType="None" />
             <message clientCredentialType="Windows" negotiateServiceCredential="true"
                            algorithmSuite="Default" establishSecurityContext="true" />
         </security>
     </binding>
    </wsHttpBinding>
</bindings>

затем добавьте изменение своей конечной точки в

<endpoint address="" binding="wsHttpBinding" bindingConfiguration="wsbind" name="wshttpbind" contract="WCFService.IService" > 

Это должно сделать это.

Ответ 5

В моем случае правило перезаписи URL-адресов было испорчено с моим именем службы, оно было переписано как строчное, и я получал эту ошибку.

Убедитесь, что вы не выполняете строчные вызовы службы WCF.

Ответ 6

Как и во многих случаях, в моей ситуации я тоже получал это из-за ошибки. И, к сожалению, я мог просто прочитать CSS страницы html error.

Источником моей проблемы было также правило перезаписи на сервере. Он переписывал http на https.

Ответ 7

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

Вы также можете просмотреть учетные данные, используемые для вызова службы.

Ответ 8

Я попробовал все вышеперечисленные предложения, но то, что работало в конце концов, заключалось в смене управляемого конвейера с пулом приложений из интегрированного режима в классический. Он работает в своем собственном пуле приложений, но это был первый сервис .NET 4.0 - все остальные сервисы на .NET 2.0, используя встроенный режим конвейера. Его стандартным сервисом WCF является https, но на сервере 2008 (не R2) - с использованием IIS 7 (не 7.5).

Ответ 9

Даже если вы не используете сетевой прокси, включение "Автоматически определять настройки" в диалоговом окне прокси делает это исключение.

Ответ 10

У меня была аналогичная ситуация, но клиентская конфигурация использовала basicHttpBinding. Проблема заключалась в том, что служба использовала SOAP 1.2, и вы не можете указать SOAP 1.2 в basicHttpBinding. Я изменил конфигурацию клиента, чтобы вместо этого использовать customBinding, и все сработало. Вот подробности моего customBinding для справки. Служба, которую я пыталась использовать, превышала HTTPS, используя UserNameOverTransport.

<customBinding>
    <binding name="myBindingNameHere" sendTimeout="00:03:00">
        <security authenticationMode="UserNameOverTransport" includeTimestamp="false">
            <secureConversationBootstrap />
        </security>
        <textMessageEncoding maxReadPoolSize="64" maxWritePoolSize="16"
              messageVersion="Soap12" writeEncoding="utf-8">
            <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
                maxBytesPerRead="4096" maxNameTableCharCount="16384" />
        </textMessageEncoding>
        <httpsTransport manualAddressing="false" maxBufferPoolSize="4194304"
              maxReceivedMessageSize="4194304" allowCookies="false" authenticationScheme="Basic"
              bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
              keepAliveEnabled="true" maxBufferSize="4194304" proxyAuthenticationScheme="Anonymous"
              realm="" transferMode="Buffered" unsafeConnectionNtlmAuthentication="false"
              useDefaultWebProxy="true" requireClientCertificate="false" />
    </binding>
</customBinding>

Ответ 11

В моем сериальном проекте WCF эта проблема связана с ссылкой на другую версию System.Web.Mvc.dll. Таким образом, это может быть проблема совместимости с DLL-версией

Когда я использую

System.Web.Mvc.dll версия 5.2.2.0 → содержит текст Ошибка Текст типа содержимого /html; charset = utf-8 ответного сообщения

но когда я использую System.Web.Mvc.dll версии 4.0.0.0 или ниже → он отлично работает.

Я не знаю причины проблемы с другой версией DLL, но, изменив DLL-версию, она работает для меня.

Эта ошибка даже генерируется при добавлении ссылки другого проекта в проект WCF, и этот справочный проект имеет другую версию DLL System.Web.Mvc или может быть любой другой DLL.

Ответ 12

X ++   binding = endPoint.get_Binding(); binding.set_UseDefaultWebProxy(false);

Ответ 13

Я решил эту проблему, установив UseCookies в web.config.

  <system.web>
    <sessionState cookieless="UseCookies" />

и установка enableVersionHeader

  <system.web>
    <httpRuntime targetFramework="4.5.1" enableVersionHeader="false" executionTimeout="1200" shutdownTimeout="1200" maxRequestLength="103424" />

Ответ 14

Если вы используете как wshttpbinding вместе с https-запросом, затем я разрешил его, используя приведенное ниже изменение конфигурации.

 <security mode="TransportWithMessageCredential">
                    <transport clientCredentialType="None" />
                    <message clientCredentialType="Certificate" />
                </security>

Ответ 15

Для меня проблема была решена, когда я прокомментировал следующую строку в Web.config

<httpErrors errorMode="Detailed" />

Ответ 16

Hy, В моем случае эта ошибка возникла из-за того, что в пуле приложений веб-службы была неправильная настройка 32/64 бит. Поэтому для этой ошибки необходимо следующее исправление: вы переходите в IIS, выбираете сайт веб-службы, переходите к настройкам Advanced и получаете пул приложений. Затем перейдите в Пулы приложений, выберите его, перейдите в "Дополнительные настройки...", выберите "Включить 32-разрядные приложения" и включите его или отключите в соответствии с 32-битным типом вашего веб-сервиса. Если параметр "Истина", это означает, что он разрешает только 32-разрядные приложения, поэтому для 64-битных приложений вам необходимо отключить "Отключить" (по умолчанию).

Ответ 17

Для меня это была строка подключения веб-приложения, указывающая на неправильный сервер базы данных.

Ответ 18

ПРИМЕЧАНИЕ. Если конечная точка целевого сервера использует сертификат уровня защищенного сокета (SSL)

Измените настройку .config с basicHttpBinding на basicHttpsBinding

Я уверен, это решит вашу проблему.

Ответ 19

Мое решение было довольно простым: сделать резервную копию всего из приложения, удалить его, удалить все из оставшихся папок (но не из папок, чтобы мне больше не пришлось предоставлять те же разрешения), а затем скопировать обратно файлы из резервной копии.