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 Gateway503 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:
- final resolved endpoint URL
- redirects
- HTTP auth or custom headers
- client certificate requirements
- 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 inAccess denied404 Not FoundRequest blockedBad 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.