GW 18.1 getUserListRequest ContentType text/html does not match

Hi,

We have a C# project with a service reference to groupwise.wsdl to handle requests to a groupwise server. 
In groupwise 8 this works but somehow a customer with version 18.1 is reporting the following error when they try to get the current userlist through our project:

The content type text/html of the response message does not match the content type of the binding (text/xml; charset=utf-8)

The call is build using a getUserListRequest that is filled with the key and name.

getUserListRequest request = new getUserListRequest()
{
key = settings.TrustedApplicationKey,
name = settings.TrustedApplicationName,
};
getUserListResponse response = null;
GroupWiseSafeProxy.DoActionAndClose(settings.Url, client => response = client.getUserListRequest(null, false, request));

Any idea why this works for GW V 8 but not anymore on GW18? Soap is enabled on the GW side, could it be that the customer must enable something else on de GW server?

Kind regards,

Walter

Parents
  • It has been a long time since I have done anything with .net. The POA is looking for a SOAP request with a request with a content type of text/xml. For some reason, the C# (.net) app is sending the request as text/html. You would probably have to debug it in the C# application. Turning on the SOAP trace at the POA level will not show the HTTP headers.

    I have had problems with different versions of .net changing how things work.

Reply
  • It has been a long time since I have done anything with .net. The POA is looking for a SOAP request with a request with a content type of text/xml. For some reason, the C# (.net) app is sending the request as text/html. You would probably have to debug it in the C# application. Turning on the SOAP trace at the POA level will not show the HTTP headers.

    I have had problems with different versions of .net changing how things work.

Children
  • Ty for the reply!

    The strange thing is, the same service version runs at a different customer environment with the same request to GW 18.2 without issues. 

    We are now waiting for the customers IT department to place the logging version of our C# service that will enable the gwTrace.