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

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

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

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

<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" > 

что должны делать это.

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

<basicHttpBinding>

до

<basicHttpsBinding>

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

также в узле измените

binding="basicHttpBinding" 

до

binding="basicHttpsBinding"

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

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

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

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

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

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

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

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

У меня была аналогичная ситуация, но конфигурация клиента использовала 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>

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

в моем проекте WCF serive эта проблема связана с ссылкой на систему.Сеть.Mvc.файлов с различных версий. Так что это может быть проблема совместимости различных версий DLL

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

тип содержимого text / html; charset=utf-8 ответного сообщения

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

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

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

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

и установка enableVersionHeader

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

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

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

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

<httpErrors errorMode="Detailed" />