0

I'm using a .NET WCF Client with C# to consume a Java WebService. When I'm sending a request to this web service, the encapsulated WCF client always put the element mustunderstand=1, even with a customized MessageInspector that implements the IClientMessageInspector changing the header elements in the method IClientMessageInspector.BeforeSendRequest. I guess the BasicHttpBinding with a BasicHttpSecurityMode.TrasportWithCredentials, always put this element in the header of the request, ignoring these manualy added headers.

This mustunderstand=1 header element is triggering an error in the server side, and this server is out of our control. Id like to avoid this header element response errors changing the value of mustunderstand=1 to mustunderstand=0.

So there is a tip or technique to change the value of this mustunderstand header parameter?

To ilustrate see the REQUEST RAW, RESPONSE RAW tracked by FIDDLER and MessageInspector.

REQUEST RAW:

POST "WSDLADDRESS" HTTP/1.1
MIME-Version: 1.0
Content-Type: multipart/related; type="application/xop+xml";start="<http://tempuri.org/0>";boundary="uuid:a0f5ee5b-4543-4aa9-85be-f7af4e8ea289+id=1";start-info="text/xml"
SOAPAction: "NAMEOFSOAPACTION"
Host: wwwh.cnj.jus.br
Content-Length: 5013
Expect: 100-continue
Accept-Encoding: gzip, deflate
Connection: Keep-Alive


--uuid:a0f5ee5b-4543-4aa9-85be-f7af4e8ea289+id=1
Content-ID: <http://tempuri.org/0>
Content-Transfer-Encoding: 8bit
Content-Type: application/xop+xml;charset=utf-8;type="text/xml"

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"><s:Header><o:Security s:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"><u:Timestamp u:Id="_0"><u:Created>2014-09-01T14:06:59.225Z</u:Created><u:Expires>2014-09-01T14:11:59.225Z</u:Expires></u:Timestamp><o:BinarySecurityToken u:Id="uuid-562fb884-7bc7-4323-ac5e-29556b6c85aa-1" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"><xop:Include href="cid:http://tempuri.org/1/635451664301180633" xmlns:xop="http://www.w3.org/2004/08/xop/include"/></o:BinarySecurityToken><Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><Reference URI="#_0"><Transforms><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><DigestValue>cIusnusCxdoCXm4BhihEXGC3MMw=</DigestValue></Reference></SignedInfo><SignatureValue>LC4d/YhYHKRocSmORNWC0oQzCrLkG00b1iSZxDL/TflCQ3pJa7qYxPY07oUR4Ngull22V9fn1QBl1NOoRii8JjK1XjJYW8XQ+pVVMnf6l2guYJjYmTp7y2p+UT3JAQrlJIYj2sAu38obsthemAtec/miY3K5anq/AYTIr1slkyDJsm23w4boq3RfTD9mbU+U+KSF71vFi5RK8ryX/i9FEsayp0N0Hpw5SP/lOEI2IkOmw4Mpg2slCLIcQWJMuP+g6aZgLviVTQBgUE3ETwdVQIogmHChfeAtHCD9Knid4Bndyldq0WoTWzGJZ9PL8PXZJIMzQtYLP+XG/emAb3Bp1g==</SignatureValue><KeyInfo><o:SecurityTokenReference><o:Reference ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" URI="#uuid-562fb884-7bc7-4323-ac5e-29556b6c85aa-1"/></o:SecurityTokenReference></KeyInfo></Signature></o:Security></s:Header><s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><consultarAvisosPendentes xmlns="http://www.cnj.jus.br/servico-intercomunicacao-2.2/"><idRepresentado xmlns="http://www.cnj.jus.br/tipos-servico-intercomunicacao-2.2"/><idConsultante xmlns="http://www.cnj.jus.br/tipos-servico-intercomunicacao-2.2"/><senhaConsultante xmlns="http://www.cnj.jus.br/tipos-servico-intercomunicacao-2.2"/><dataReferencia xmlns="http://www.cnj.jus.br/tipos-servico-intercomunicacao-2.2">01/09/2014</dataReferencia></consultarAvisosPendentes></s:Body></s:Envelope>
--uuid:a0f5ee5b-4543-4aa9-85be-f7af4e8ea289+id=1
Content-ID: <http://tempuri.org/1/635451664301180633>
Content-Transfer-Encoding: binary
Content-Type: application/octet-stream

0��0�ΠZN�(K��20�    ���j0
    *�H��

�0o1
0   UBR10U

(...certificate data...)
�����2o�w�|� ������#�d�e�Z9�KI��l����ɵ�v���Ka�����q�晚=]�ht���l�T�x�7<IS�d@��T�d՘�30��T;l��3�ЉJ�K(���tP��oU�結$�"�4�4�x����p����\ނl�/0鈾yN�
iu����y�-��Z�J���<���P�5�i}��;&u�t�DH�oc��@D�Mf}ue��I\Mk�鐈�^gF�_T'䌁U��ёN����qy;�P_����7F�dz��qLL
�`g>
�C�﨨�%��a;���z�����n�$��O�Vz4��ѡ�D��V�3�X�!m��y���E��E��};��)�Jlv��+��6���RK
�����w��k���@�XIB����?��qC��ġ��6n{n��s�̔-���
|�����@+�Jv�r�%̓p�� *gy4��(�hA�⮫*m��bU��c�>����}��h�����Y�(
--uuid:a0f5ee5b-4543-4aa9-85be-f7af4e8ea289+id=1--

RESPONSE RAW:

HTTP/1.1 500 Internal Server Error
Date: Mon, 01 Sep 2014 14:07:10 GMT
X-Powered-By: Servlet 2.5; JBoss-5.0/JBossWeb-2.1
Content-Type: text/xml;charset=UTF-8
Vary: Accept-Encoding
Connection: close
Content-Length: 480

<env:Envelope xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'><env:Header></env:Header><env:Body><env:Fault xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'><faultcode xmlns:codeNS='http://schemas.xmlsoap.org/soap/envelope/'>codeNS:MustUnderstand</faultcode><faultstring>Unprocessed &apos;mustUnderstand&apos; header element: {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security</faultstring></env:Fault></env:Body></env:Envelope>

MessageInspector:

    class MessageInspector : IClientMessageInspector
    {
        object IClientMessageInspector.BeforeSendRequest(ref System.ServiceModel.Channels.Message request, System.ServiceModel.IClientChannel channel)
        {
            request.Headers.Add(MessageHeader.CreateHeader
                (request.Headers[0].Name,
                request.Headers[0].Namespace,
                string.Empty,
                false,
                request.Headers[0].Actor,
                request.Headers[0].Relay)
                );

            request.Headers.RemoveAt(0);

            return Convert.DBNull;
        }

        public void AfterReceiveReply(ref Message reply, object correlationState)
        {
        }
    }

Request Headers Before:

Request Headers Before

Request Headers After:

Request Headers After

SteveC
  • 15,808
  • 23
  • 102
  • 173
Castello
  • 54
  • 1
  • 5
  • Can you show your `MessageInspector` implementation? – dyson Sep 01 '14 at 15:15
  • Hy @barrick , Ok! I added it in the post. But even adding the header by hand, the client, made by wcf ignore the "false" parameter, and put the "mustunderstand=1" element in the header. – Castello Sep 01 '14 at 16:41
  • I see. If you put a breakpoint after the `request.Headers.RemoveAt(0)` method call, does your message have the required headers at that point? – dyson Sep 01 '14 at 17:49
  • Yes, after this point the property MustUnderstand is "false", so the header of the request should be "mustunderstand=0". I added some pics to ilustrate that. – Castello Sep 01 '14 at 18:14

1 Answers1

1

Okay...this will take some work to get right. I don't know if you're familiar with the channel stack within a binding, but basically, the message will flow through various operations within WCF, each of which will transform the message in some way.

This answer, and the use of custom message encoders is what you need to do, as WCF is applying the 'correct' headers (as it sees it, due to the specified binding) after you have amended the header to remove the mustUnderstand attribute.

It's a rather complex area, I had to use it to get a SOAP header generated by WCF to conform to something that WSE 3.0 used to create, with a binary Token in the Security header; but with a bit of trial and error, it is a very powerful feature.

Community
  • 1
  • 1
dyson
  • 866
  • 6
  • 12