Introduction

This WCF error usually means the client expected a SOAP or XML response, but the server actually returned an HTML page. That HTML is often not the real payload at all. It is typically an IIS error page, an authentication redirect, a 404 response, or some other infrastructure page that WCF cannot parse using the configured binding.

What the Error Really Means

A SOAP client configured with basicHttpBinding or wsHttpBinding expects content such as text/xml or application/soap+xml. If the server responds with text/html; charset=utf-8, WCF reports a protocol exception because the response body does not match the binding's message encoder.

That means the first debugging question is not "How do I make WCF accept HTML?" It is "Why did the server send HTML instead of the service response?"

Inspect the Actual HTTP Response

Use a tool that shows the raw response, not just the .NET exception.

curl -i http://localhost/OrderService.svc

Or if the endpoint expects SOAP, hit the metadata URL and confirm it is reachable:

curl -i http://localhost/OrderService.svc?wsdl

You can also inspect the response with Fiddler or browser developer tools. Common real responses include:

• '404 Not Found rendered as an HTML page'
• '500 Internal Server Error from IIS or ASP.NET'
• a login page caused by Windows or forms authentication
• a reverse-proxy error page from a gateway in front of the service

Once you see the actual page, the mismatch becomes easier to explain.

Check the Endpoint and Binding Match

The client endpoint address and the service binding must agree. If the service exposes SOAP but the client points to the wrong path, WCF may hit an ASP.NET route or static page instead.

A typical SOAP client endpoint looks like this:

1<system.serviceModel>
2  <bindings>
3    <basicHttpBinding>
4      <binding name="OrderBinding" />
5    </basicHttpBinding>
6  </bindings>
7  <client>
8    <endpoint
9      address="http://localhost/OrderService.svc"
10      binding="basicHttpBinding"
11      bindingConfiguration="OrderBinding"
12      contract="OrderServiceReference.IOrderService" />
13  </client>
14</system.serviceModel>

If the service is actually REST, JSON, or a plain MVC endpoint, a SOAP binding is the wrong client entirely.

Authentication and Redirects Are Common Causes

One of the most common reasons for text/html is a redirect to a login page. The WCF client follows the HTTP flow and ends up receiving HTML from the authentication layer rather than XML from the service.

Check whether the URL works from the same process identity that the client uses. If IIS or the proxy requires authentication, configure that in the client instead of assuming the endpoint is public.

var client = new OrderServiceClient();
client.ClientCredentials.Windows.ClientCredential =
    System.Net.CredentialCache.DefaultNetworkCredentials;

The exact credentials depend on your hosting setup, but the principle is the same: if authentication fails, the server may respond with HTML.

Do Not "Fix" It by Accepting HTML

It is sometimes tempting to replace the binding or message encoder so the client stops throwing the content-type exception. That usually hides the real problem. If a SOAP client receives HTML, the correct fix is almost always to repair the server response path, not to teach the client to accept the wrong payload type.

A productive workflow is:

1. confirm the endpoint URL is correct
2. inspect the raw HTTP response
3. verify authentication and authorization behavior
4. confirm the service really exposes the binding the client expects
5. only then adjust client configuration if the service contract truly changed

Common Pitfalls

• Treating the exception as a client parser problem instead of checking the raw HTTP response.
• Pointing the client at the wrong URL and receiving an IIS 404 or MVC page.
• Ignoring authentication redirects that return HTML login pages.
• Using a SOAP binding against a non-SOAP endpoint.
• Trying to make WCF accept text/html instead of fixing the upstream error.

Summary

• The error means the client expected SOAP or XML but received HTML.
• The HTML response is usually an error page, redirect, or wrong endpoint.
• Inspect the raw HTTP response with curl, Fiddler, or similar tools.
• Verify that the endpoint address, binding, and authentication setup all match the actual service.
• Fix the server response path rather than teaching the client to accept HTML.