Connecting to webservice results in com.sun.xml.internal.ws.client.ClientTransportException: The server sent HTTP status code 200: OK

Question

I made wsdl using sun-jaxws. I created web service client in Netbeanse, and successfully called wsdl web service. Then I configured my nginx server to access web service by https. When I call service over https I get error com.sun.xml.internal.ws.client.ClientTransportException: The server sent HTTP status code 200: OK

My wsdl available by address https://somesite.com/mywsdl/?wsdl . Inside the wsdl I see such service location:

<service name="GenericService"> <port name="GenericServicePort" binding="tns:GenericServicePortBinding"> <soap:address location="https://somesite.com:443/mywsdl"/> </port> </service>

I don't know whether the problem in my nginx configuration, or in my jaxws.

Answer 1

The problem was in the extra slash in my url. I changed url from https://somesite.com/mywsdl/?wsdl to https://somesite.com/mywsdl?wsdl and the problem disappeared.

Answer 2

You usually get the ClientTransportException: The server sent HTTP status code 200: OK when the SOAP server, that your client connects to, sends a response with content-type text/html .

We can see that in the following code: com.sun.xml.ws.transport.http.client.HttpTransportPipe (from jaxws-rt , or the same class from the internal JRE package com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe )

if (contentType != null && contentType.contains("text/html") && binding instanceof SOAPBinding) {
    throw new ClientTransportException(ClientMessages.localizableHTTP_STATUS_CODE(con.statusCode, con.statusMessage));
}

Normally when you receive an answer from a SOAP server, you should get the following content types as a response:

• SOAP v1.1 uses content-type text/xml
• SOAP v1.2 uses content-type application/soap+xml

When the response is marked as HTML, it's either one of the following issues:

• your request is made to the wrong endpoint, and you are presented with some HTML status page (for example SOAPUI also does this on unknown mock endpoints)
• your request is invalid for the given endpoint, and the server doesn't send a proper SOAPFault
• your request is valid, but the server is having issues processing it (for example HTTP4xx or HTTP5xx not found/error pages as HTML. But these usually don't have code 200 OK), and doesn't or can't send a proper SOAPFault

In any case if you're trying to debug this, your first step should be to enable the following vmoptions on your SOAP client:

-Dcom.sun.xml.ws.transport.http.client.HttpTransportPipe.dump=TRUE
-Dcom.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.dump=TRUE
-Dcom.sun.xml.ws.transport.http.HttpAdapter.dump=TRUE
-Dcom.sun.xml.internal.ws.transport.http.HttpAdapter.dump=TRUE
-Dcom.sun.xml.internal.ws.transport.http.HttpAdapter.dumpTreshold=999999

These will dump/log the entire HTTP request + response (headers and body). With this you can analyze where the error exactly is, based on the endpoint and the (possible) HTML page body. Possibly HTML, because it can also very well be a normal SOAPFault XML with just the wrong content-type header (if the server is not implemented correctly).

For more information on SOAP issues like this you can also read the following questions:

• UnsupportedMediaException -> how do you get the actual response?
• Unsupported Content-Type: text/xml; charset=utf-8 Supported ones are: [application/soap+xml]