none
WCF client talking to Java WS, exception: The content type application/xop+xml; type="application/soap+xml" of the response message does not match... RRS feed

  • Question

  • Hi all,

    I'm having problems talking to Java WS. I'm using "wsHttpBinding" binding with client certificates for authentication, message encoding is set "Text", .net framework is 4.0. Server side is Java and I have no control over it. Connection is being proxied through Fiddler (this is how I see requests on the wire, much more user friendly than tracing "System.Net").

    Exception I get is following:

    The content type application/xop+xml; type="application/soap+xml" of the response message does not match the content type of the binding (application/soap+xml; charset=utf-8).

    If I change message encoding to "Mtom", then the exception changes:

    The content type application/xop+xml; type="application/soap+xml" of the response message does not match the content type of the binding (multipart/related; type="application/xop+xml").

    Server is accepting both "Text" and "Mtom" message encodings for request, and response is always the same. This is the raw response that I get from the server:

    HTTP/1.1 200 OK
    X-Backside-Transport: OK OK
    Connection: Keep-Alive
    X-Powered-By: Servlet/3.0
    SOAPAction: ""
    Content-Type: application/xop+xml; type="application/soap+xml"
    Content-Language: en-US
    Date: Thu, 25 Jul 2013 13:05:09 GMT
    Content-Length: 628
    
    <?xml version="1.0" encoding="UTF-8"?>
    <env:Envelope  ...   </env:Envelope>


    From all the docs which I have been reading, response that is being returned is somewhere between regular SOAP message and MTOM message. I'm saying this because all the examples which I've seen say that the MTOM request and response should use MIME as an envelope for communication, example response for MTOM with binary attachment: "http://metro.java.net/2.1.1/guide/Binary_Attachments__MTOM_.html". Important excerpt from this link:

    Content-Type: Multipart/Related; start-info="text/xml"; type="application/xop+xml"; boundary...

    If I try calling service using tool soapUI (written in Java) from "www.soapui.org", service call is successfully called and response is parsed without any problem.

    Any idea is appreciated,

    Alex


    Thursday, July 25, 2013 2:34 PM

Answers

  • Hi Amy,

    thank you for the help, I did look into all the links you've posted, but unfortunately nothing helped.

    I did however succeed in calling few of the service methods (using "SoapUI"), and each method I invoked had different binding (and also different response headers). As this is government body (customs), there is a zero chance of changing their setup (to follow standards as they are claiming to be).

    So in the end it's not working using WCF out of the box, and I'm still deciding on custom message parsing using WCF vs. using Java for communicating with service.

    P.S. Sorry for not replying sooner, I was on a leave without Internet access.

    Thanks again,

    Alex

    • Marked as answer by alemarko Thursday, August 8, 2013 12:28 PM
    Thursday, August 8, 2013 12:27 PM

All replies

  • The content type application/xop+xml; type="application/soap+xml" of the response message does not match the content type of the binding (application/soap+xml; charset=utf-8).


    Hi,

    When occur this problem, it may be caused by binding setting mismatch between client and service. So please try to check it.

    Here are some similar threads:

    http://wcfpro.wordpress.com/2011/01/11/encoderfallbackexception-when-passing-utf8-characters/ .

    http://social.msdn.microsoft.com/Forums/en-US/13e21af4-8dfa-4e23-abbf-d85d3f9f1fc1/the-content-type-texthtml-charsetutf8-of-the-response-message-does-not-match-the-content-type-of .

    http://social.msdn.microsoft.com/Forums/en-US/63623c7b-69da-4975-b9fb-d707d2d02699/the-content-type-texthtml-charsetutf8-of-the-response-message-does-not-match-the-content-type-of .

    If your problem still can not be solved, please try to post your configure file here.

    Best Regards.


    Amy Peng
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.



    Monday, July 29, 2013 4:36 AM
    Moderator
  • Hi Amy,

    thank you for the help, I did look into all the links you've posted, but unfortunately nothing helped.

    I did however succeed in calling few of the service methods (using "SoapUI"), and each method I invoked had different binding (and also different response headers). As this is government body (customs), there is a zero chance of changing their setup (to follow standards as they are claiming to be).

    So in the end it's not working using WCF out of the box, and I'm still deciding on custom message parsing using WCF vs. using Java for communicating with service.

    P.S. Sorry for not replying sooner, I was on a leave without Internet access.

    Thanks again,

    Alex

    • Marked as answer by alemarko Thursday, August 8, 2013 12:28 PM
    Thursday, August 8, 2013 12:27 PM
  • Alex,

    I have a feeling this is the MOHLTC's EBS service, correct? I've solved that issue with the library EBSconnect. Check it out. The biggest issue here was that it's not strictly MTOM, it's actually MTOM served through Soap With Attachments in a very non-standard way. Took quite a while to get that part completed, espeically since you also have to decrypt the XML content to then replace the XOP MTOM nodes with the attached content BEFORE deserializing.


    Kori Francis Lead Software Developer Clinical Support Systems, Inc.

    Thursday, March 20, 2014 4:41 PM
  • Hi Kori,

    my source of happiness is Croatian Customs Administration.

    I ended with the same solution: I intercept messages, fix

    them up to look as samples in W3C docs and then deserialize them. 

    But it's so messy, I have a feeling that instead of MTOM

    messaging, I've ended with MITM messaging :-))

    BR,

    Alex

    Monday, March 24, 2014 7:45 PM
  • I have the same problem. I have a WindowsForms Application in Visual Studio 2010, the web service is Java and i have this error:

    "The content type application/soap+xml; charset=utf-8" of the response message does not match  the content type of the binding (application/soap+xml; charset=utf-8). "

    this is my app.config:

    <?xml version="1.0" encoding="utf-8" ?>
    <configuration>
      <system.serviceModel>    
        <bindings>
          <basicHttpBinding>
            <binding name="IDAWSBinder"  messageEncoding="Mtom">
              <security mode="Transport">
                <transport clientCredentialType="None" />
              </security>
            </binding>
          </basicHttpBinding>
        </bindings>

        <client>
          <endpoint address="https://ws142.juntadeandalucia.es/agriculturaypesca/idaServicepru/"
            binding="basicHttpBinding" bindingConfiguration="IDAWSBinder"
            contract="IDAWS.IDAWSPortType" name="IDAWSPortType" />
        </client>
      </system.serviceModel>
    </configuration>

    Excuse me for my bad English. I need help.

    Monday, August 4, 2014 12:53 PM
  • Hi Alex,

    Would you mind sharing the solution you came up with? Seems like there should be something available now to solve this problem.

    Thanks in advance,

    Shaung

    Tuesday, November 18, 2014 5:38 PM
  • Hi Shaung,

    I'm sorry I could not respond sooner. Do you still need the code?

    I'm asking because it's not trivial to extract it, as it's not used anymore.

    My problems went away because the government body in question fixed the mess.

    In my experience and what I've seen online, these kind of problems

    are frequent in EU with government bodies (they use old versions of Java

    server apps and frameworks).

    Just to warn you, code is a mess. It was only tested on .net 4.0 and uses

    reflection to change the messages when they arrive. So scripting SoapUI as external

    application would be much safer option.  

    BR,

    Alex

    Monday, November 24, 2014 9:00 AM