5

I am attempting to develop a web application that submits a simple login request to a web service using WCF, but I keep getting "content type text/plain of the response message does not match" errors, even though the web service appears to be returning valid XML.

I've reviewed the dozens of similar S.O. posts regarding this error and have ruled out the more common possibilities:

  1. I can see in the response that it's not an Error page coming back (as discussed here).
  2. I don't appear to have a binding mismatch issue (as discussed here). My app and the web service are both using SOAP 1.1 and I have "basicHttpBinding" specified.
  3. The response included in my error message appears to show valid XML that includes the user and response variables that I want.
  4. I can see in the Web Service log files that the login method is fully executing without throwing an exception.
  5. I pasted the XML response into the W3Schools validator with no error.

What else could be causing my error, and why isn't this being recognized as valid XML?

I am using .Net 4.0 and Visual Studio 2010 for my application, which is communicating with a Java/Tomcat web service on a separate server.

Here are the relevant excerpts from my login code:

AuthenticationServiceClient client = new AuthenticationServiceClient(strPortName, strURL);
client.Open();
UserCredentials credentials = new UserCredentials();
credentials.userName = TestUsername;
credentials.password = TestPassword;
LoginResponse response = client.login(credentials); // Using WCF.

Here is what the binding looks like in my Web.Config:

<system.serviceModel>
  <bindings>
    <basicHttpBinding>
      <binding name="AuthenticationServiceSoapBinding" />
    </basicHttpBinding>
  </bindings>
  <client>
    <endpoint address="http://mywebserviceurl"
      binding="basicHttpBinding" bindingConfiguration="AuthenticationServiceSoapBinding"
      contract="MyNamespace.AuthenticationService" name="AuthenticationServiceImplPort" />
  </client>
</system.serviceModel>

Here is my Error Message:

Error testing connection to web service at "WebServiceURL": System.ServiceModel.ProtocolException: The content type text/plain of the response message does not match the content type of the binding (text/xml; charset=utf-8). If using a custom encoder, be sure that the IsContentTypeSupported method is implemented properly. The first 788 bytes of the response were: '

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<loginReponse xmlns="urn:xxxx">
<authKey>xxxx</authKey>
<authMetadata>
<IPaddress>https://MyWebApplicationURL</IPaddress>
<loginTimestamp>xxxx</loginTimestamp><levelOfAssurance>
<AuthMechanism>xxxx</AuthMechanism>
<VettingAssertion>xxxx</VettingAssertion>
</levelOfAssurance>
</authMetadata>
<errorText></errorText>
<successfulLoginFlag>true</successfulLoginFlag>
<userSummary>
<GUID>xxxx</GUID>
<commonName>xxxx</commonName>
<loginName>xxxx</loginName>
</userSummary>
<passwordExpiryDays>xxxx</passwordExpiryDays></loginReponse>
</soap:Body>
</soap:Envelope>

'.

Server stack trace: at System.ServiceModel.Channels.HttpChannelUtilities.ValidateRequestReplyResponse(HttpWebRequest request, HttpWebResponse response, HttpChannelFactory factory, WebException responseException, ChannelBinding channelBinding) at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout) at System.ServiceModel.Channels.RequestChannel.Request(Message message, TimeSpan timeout) at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout) at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation) at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]: at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg) at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type) at MyNamespace.AuthenticationService.AuthenticationService.login(loginRequest request) at MyNamespace.AuthenticationService.AuthenticationServiceClient.MyNamespace.AuthenticationService.AuthenticationService.login(loginRequest request) in C:...\AuthenticationService\Reference.cs:line 1716 at MyNamespace.AuthenticationService.AuthenticationServiceClient.login(UserCredentials credentials) in C:...\AuthenticationService\Reference.cs:line 1722
at MyNamespace.Forms.TestWebService.TestLogin_Click(Object sender, EventArgs e) in C:...\TestWebService.aspx.cs:line 284

Here is what my response from the Web Service looks like in WireShark:

WireShark Screenshot

Community
  • 1
  • 1
Mac
  • 1,201
  • 2
  • 15
  • 28
  • If you use any sniffer (f.ex. Fiddler) and you create a request to the server what do you get back? Just looking at your problem it seems that you are requesting a proper 1.1 SOAP message but you get a "text/plain" message returned, which isn't what your application is expecting and there for throws the exception. I might be pointing out the obvious here, but anymore info you get could be very vital here. – Thomas Lindvall Feb 06 '14 at 03:29
  • What I'm getting back appears to be the XML displayed after the "The first 788 bytes of the response were" in my exception that is being thrown. I don't have local firewall access to the Web Service, only from my test deployment server. I'll likely test this with WireShark next, but I expect that that will just verify that my XML response matches the XML response included in the exception text. – Mac Feb 06 '14 at 14:32
  • Feel free to suggest the "obvious" though. I very well might be missing something obvious. Thank you. – Mac Feb 06 '14 at 14:34
  • Do you get the same exception thrown if you change the basicHttpBinding to a webHttpBinding? – Thomas Lindvall Feb 06 '14 at 15:01
  • "webHttpBinding" is just for REST right? I'm connecting to a SOAP service. The Service is built with JAX-WS and includes a WSDL. – Mac Feb 06 '14 at 16:01
  • webHttp handels any POX, JSON, CSV or similar that you can think of, yes it handels RESTful services (and the widely spread misunderstanding of what REST is), but think of it as tiers, where the regular webhttp is the lowest and the ws is the highest, I think you get a valid POX back that looks just like a SOAP message but it's actually POX, that's why I suggest trying with the webHttpbinding. – Thomas Lindvall Feb 06 '14 at 17:04
  • Can you please share the binding that you have for the service in web.config ? – Thanigainathan Feb 06 '14 at 18:09
  • I've added my Web.Config binding settings and a WireShark screenshot. – Mac Feb 06 '14 at 19:18
  • 1
    And the service is written in Java/Tomcat? If so could the problem be there? Is there another consumer of the webserver that doesn't get the response as "text/plain"? – Dirk Feb 08 '14 at 13:08
  • Looks like text/plain is in the response headers from the service. – iamkrillin Feb 09 '14 at 16:18
  • Yes, "text/plain" is in the response header. However, a different highly used Java application is successfully consuming an identical deployment of the service without error. I still suspect that something in my Service Reference configuration is affecting the formatting of the response. Also, my test application is not connecting over SSL if that would make a difference. – Mac Feb 10 '14 at 14:04

2 Answers2

7

The problem is that the service is responding with text/plain when it should be responding with text/xml or application/xml which is what your WCF binding expects in order to properly handle it. Fundamentally this is an "issue" on the service side: they are returning XML but calling it plaintext, which technically is accurate but not as specific as an XML content type. On the WCF side, the built-in protocol handling is fairly rigid and expects the content type to be text/xml or application/xml in order to proceed with deserializing it.

You could thwart their content type problem by writing a custom WCF encoder that supports text/plain but parses it as XML.

Haney
  • 32,775
  • 8
  • 59
  • 68
0

this issue can occur if WCF Activation Components have not been installed. Please check below link for more information and similar issue faced

http://bit.ly/1fYZ2wn