WCF service client: text of type content / html; charset = utf-8 of the response message does not match the content type of the binding

I have a WCF service running on my local IIS server. I added it as a website link for the C # Website project, and it adds a penalty and automatically generates proxy classes.

However, when I try to call any of the service contracts, I get the following error:

Description: An unhandled exception occurred during the execution of the current web request. View the stack trace for more information about the error and its occurrence in the code.

Exception Details: System.ServiceModel.ProtocolException: Content Type text / html; charset = utf-8 of the response message does not match the content type of the binding (application / soap + xml; charset = utf-8). If you use a custom encoder, make sure that the IsContentTypeSupported method is implemented correctly. The first 1024 bytes of the response were: "function bredir (d, u, r, v, c) {var w, h, wd, hd, bi; var b = false; var p = false; var s = [[300250, false ], [250,250, false], [240400, false], [336280, false], [180150, false], [468.60, false], [234.60, false], [88.31, false], [120.90, false], [120.60, false], [120240, false], [125125, false], [728.90, false], [160600, false], [120600, false], [300600 , false], [300125, false], [530300, false], [190200, false], [470250, false], [720300, true], [500350, true], [550480, true]]; if (typeof (window.innerHeight) == 'number') {h = window.innerHeight; w = window.innerWidth;} else if (typeof (document.body.offsetHeight) == 'number') {h = document. body.offsetHeight ; w = document.body.offsetWidth;} for (var i = 0; i

I also have a console application that also interacts with the WCF service, and the console application can call methods efficiently without getting this error.

The following are excerpts from my configuration files.

WCF Web.Config Service:

<system.serviceModel> <services> <service name="ScraperService" behaviorConfiguration="ScraperServiceBehavior"> <endpoint address="" binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IScraperService" contract="IScraperService" /> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> <host> <baseAddresses> <add baseAddress="http://example.com" /> </baseAddresses> </host> </service> </services> <bindings> <wsHttpBinding> <binding name="WSHttpBinding_IScraperService" bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard" maxBufferPoolSize="2000000" maxReceivedMessageSize="2000000" messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true" allowCookies="false"> <readerQuotas maxDepth="2000000" maxStringContentLength="2000000" maxArrayLength="2000000" maxBytesPerRead="2000000" maxNameTableCharCount="2000000" /> <reliableSession enabled="false" ordered="true" inactivityTimeout="00:10:00" /> <security mode="Message"> <message clientCredentialType="Windows" negotiateServiceCredential="true" algorithmSuite="Default" establishSecurityContext="true" /> </security> </binding> </wsHttpBinding> </bindings> <behaviors> <serviceBehaviors> <behavior name="ScraperServiceBehavior"> <serviceMetadata httpGetEnabled="true" /> <serviceDebug includeExceptionDetailInFaults="true" /> </behavior> </serviceBehaviors> </behaviors> </system.serviceModel> 

Website Project Service Client Web.Config :

 <system.serviceModel> <bindings> <wsHttpBinding> <binding name="WSHttpBinding_IScraperService" closeTimeout="00:01:00" openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00" bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard" maxBufferPoolSize="524288" maxReceivedMessageSize="65536" messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true" allowCookies="false"> <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384" maxBytesPerRead="4096" maxNameTableCharCount="16384" /> <reliableSession enabled="false" ordered="true" inactivityTimeout="00:10:00" /> <security mode="Message"> <transport clientCredentialType="Windows" proxyCredentialType="None" realm="" /> <message clientCredentialType="Windows" negotiateServiceCredential="true" algorithmSuite="Default" /> </security> </binding> </wsHttpBinding> </bindings> <client> <endpoint name="WSHttpBinding_IScraperService" address="http://example.com/ScraperService.svc" binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IScraperService" contract="ScraperService.IScraperService" > <identity> <servicePrincipalName value="host/FreshNET-II" /> </identity> </endpoint> </client> </system.serviceModel> 

This is my first attempt to create WCF, so this is all very new. Any help is much appreciated.

+61
c # web-services wcf
Mar 09 2018-11-11T00:
source share
18 answers

Try going to http: //localhost/ScraperService.svc in a web browser on the server hosting the service, using the same Windows credentials that are usually executed by the client.

I assume that IIS displays an html error message of some description instead of returning xml as expected.

This can also happen if you have an HTTP proxy server that performs filtering over the Internet. My experience with ContentKeeper is that it intercepts any http / https traffic and blocks it as "Unmanaged content" - all we get is an html error message. To avoid this, you can add proxy exclusion rules to Internet Explorer so that the proxy server does not intercept traffic to your site:

Control Panel> Internet Options> Connections> LAN Settings> Advanced> Proxy Settings

enter image description here

+26
Mar 09 '11 at 12:16
source share

An HTML response on a web server usually indicates that an error page was displayed instead of a response from the WCF service. My first suggestion was to verify that the user you are managing the WCF client has access to the resource.

+17
Mar 09 2018-11-11T00:
source share

I had a similar problem. I resolved this by changing

 <basicHttpBinding> 

to

 <basicHttpsBinding> 

and also changed my url to use https: // instead of http: //.

Also in the <endpoint> node, change

 binding="basicHttpBinding" 

to

 binding="basicHttpsBinding" 

It worked.

+13
Aug 01 '16 at 18:39
source share

what happens, you are trying to access the service using wsHttpBind, which by default uses secure encrypted messages (secure messages). NetTcpBind, on the other hand, uses secure encrypted channels. (Secured transport) ... BUT basicHttpBind, does not require any security whatsoever and can access anonymous

SO. on the server side, add \ Modify this to your configuration.

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

then add your endpoint change to

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

That should do it.

+5
Oct 26 '12 at 1:17
source share

In my case, the URL rewrite rule was messed up with my service name, it was rewritten as lowercase, and I got this error.

Make sure you are not making line calls to the WCF service.

+1
Nov 13 '11 at 2:48
source share

As in many cases, in my situation I also received this because of an error. And unfortunately, I could just read the CSS pages of the html error.

The source of my problem was also the rewrite rule on the server. He was rewriting http to https.

+1
May 23 '12 at 20:43
source share

You can check the configuration of your service and make sure that everything is in order. You can go to the web service through the browser to see if the scheme will be displayed in the browser.

You can also view the credentials used to call the service.

+1
Jun 27 '12 at 21:10
source share

I tried all of the above suggestions, but what worked in the end was to change the managed pipeline with the application pool from integrated mode to classic. It works in its own application pool, but it was the first .NET 4.0 service — all other services on .NET 2.0 using the built-in pipeline mode. Its standard WCF service is https, but on server 2008 (not R2) - using IIS 7 (not 7.5).

+1
Nov 02
source share

Even if you are not using a network proxy, the inclusion of "Automatically detect settings" in the proxy dialog makes this exception.

enter image description here

+1
Apr 29 '14 at 13:43 on
source share

I had a similar situation, but the client configuration used basicHttpBinding. The problem was that the service was using SOAP 1.2, and you cannot specify SOAP 1.2 in basicHttpBinding. I changed the client configuration to use customBinding instead, and it worked. Here are the details of my customBinding for reference. The service I was trying to use exceeded HTTPS using 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> 
+1
Feb 24 '16 at 19:14
source share

In my serial WCF project, this problem is related to a link to another version of System.Web.Mvc.dll. So it could be a compatibility issue with the dll version

When i use

System.Web.Mvc.dll version 5.2.2.0 → contains the text Error Text content type / html; charset = utf-8 response message

but when I use System.Web.Mvc.dll version 4.0.0.0 or lower -> it works fine .

I do not know the cause of the problem with another version of the DLL, but by changing the DLL version, it works for me.

This error is even generated when adding the link of another project to the WCF project, and this reference project has a different version of the System.Web.Mvc DLL or it can be any other DLL.

+1
Nov 07 '16 at 7:44
source share

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

0
Jan 29 '14 at
source share

I solved this problem by setting UseCookies in web.config.

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

and setting enableVersionHeader

  <system.web> <httpRuntime targetFramework="4.5.1" enableVersionHeader="false" executionTimeout="1200" shutdownTimeout="1200" maxRequestLength="103424" /> 
0
May 6 '16 at 1:04
source share

If you use as wshttpbinding along with the https request, then I resolved it using the configuration change below.

  <security mode="TransportWithMessageCredential"> <transport clientCredentialType="None" /> <message clientCredentialType="Certificate" /> </security> 
0
Feb 25 '17 at 9:33
source share

For me, the problem was resolved when I commented on the next line in Web.config

 <httpErrors errorMode="Detailed" /> 
0
Sep 14 '17 at 3:51 on
source share

Hy, In my case, this error occurred because the 32/64 bit setting was incorrect in the web service application pool. Therefore, for this error, the following correction is required: you go to IIS, select the web service site, go to Advanced settings and get the application pool. Then go to Application Pools, select it, go to "Advanced Settings ...", select "Enable 32-bit Applications" and enable or disable it according to the 32-bit type of your web service. If the parameter is True, this means that it only allows 32-bit applications, so for 64-bit applications you need to disable "Disable" (by default).

0
Nov 14 '18 at 13:52
source share

For me, it was a web application connection string pointing to the wrong database server.

0
Mar 25 '19 at 7:33
source share

NOTE. If the destination server endpoint uses a secure socket level (SSL) certificate

Change the .config setting from basicHttpBinding to basicHttpsBinding

I am sure this will solve your problem.

0
Sep 02 '19 at 14:00
source share



All Articles