soap-errorscontent-typeauth

Content Type text/html; charset=utf-8 was not supported by service: What It Really Means

SOAPless Team2 min read

This error message looks like a SOAP parsing problem, but in practice it usually means you never got a SOAP response at all.

Content Type text/html; charset=utf-8 was not supported by service

Your client expected XML. The server returned HTML. That HTML is often one of these:

  • a login page
  • a reverse proxy error page
  • a 404 page
  • an internal corporate gateway warning

The real first step

Stop looking at the client exception and inspect the raw response body.

curl -i https://example.com/service.svc

If you see <!DOCTYPE html> or <html>, you are not talking to the SOAP service correctly.

Most common causes

1. You are hitting the wrong URL

Developers often send the SOAP request to the WSDL URL instead of the service endpoint.

Wrong:

https://example.com/service.svc?wsdl

Correct:

https://example.com/service.svc

Check the <soap:address location="..."> in the WSDL and use that.

2. You are being redirected to a login page

This is extremely common behind enterprise gateways.

curl -I https://example.com/service.svc

If you see 302 Found or Location: /login, the SOAP service is behind an authentication wall and your current client is not satisfying it.

3. The proxy or load balancer is returning HTML

Upstream outages often look like:

  • 502 Bad Gateway
  • 503 Service Unavailable
  • custom HTML from F5, nginx, or an SSO layer

The SOAP client sees the wrong content type and throws the content-type error, but the real problem is higher up the stack.

What to verify

Check all of these:

  1. final resolved endpoint URL
  2. redirects
  3. HTTP auth or custom headers
  4. client certificate requirements
  5. whether the endpoint expects SOAP 1.1 or SOAP 1.2
curl -vk https://example.com/service.svc \
  -H 'Content-Type: text/xml; charset=utf-8' \
  -H 'SOAPAction: "http://tempuri.org/GetUser"' \
  --data @request.xml

The -v output will often show the redirect or proxy layer immediately.

If the body is HTML, read the title tag

That one line often tells you the actual problem:

  • Sign in
  • Access denied
  • 404 Not Found
  • Request blocked
  • Bad Gateway

That is much more actionable than the SOAP client exception.

Long-term fix

If different callers keep hitting different gateways or auth paths, the integration stays fragile. A single managed proxy layer in front of the SOAP endpoint reduces that drift and gives your app a stable JSON-facing endpoint.