none
no security in wsHttpBinding fails when explict but works when omitted RRS feed

  • Question

  • So the below config settings for a WCF service will generate a (non critical? because the service continues to work, just throws at startup... maybe this is mex related?):

    The message with Action 'http://schemas.xmlsoap.org/ws/2004/09/transfer/Get' cannot be processed at the receiver, due to a ContractFilter mismatch at the EndpointDispatcher. This may be because of either a contract mismatch (mismatched Actions between sender and receiver) or a binding/security mismatch between the sender and the receiver.  Check that sender and receiver have the same contract and the same binding (including security requirements, e.g. Message, Transport, None).

          <wsHttpBinding>
            <binding name="WSHttpBinding_Ninjas">
              <security mode="None">
                <transport clientCredentialType="None" />
                <message establishSecurityContext="false" />
              </security>
            </binding>
    
    or even
    
          <wsHttpBinding>
            <binding name="WSHttpBinding_Ninjas">
              <security mode="None" />
            </binding>
    
    except this works and does not produce these errors
    
          <wsHttpBinding>
            <binding name="WSHttpBinding_Ninjas">
            </binding>

    This had me scratching my head for weeks before I played with the settings and solved this myself...

    At first I thought it was just the way the WCFTestClient handles the client side config, but these errors seem to occur in production also (unless the WCF AND the clients we are connecting are using the same process...)

    Mostly I'm just curious now... anyone got any insights?


    - sure I'm noJedi but that's no reason to stop trying to make stuff levitate! -


    • Edited by noJedi Saturday, May 21, 2016 11:23 AM
    Saturday, May 21, 2016 11:22 AM

All replies

  • Hi noJedi,

    I have used the following config file in my side:

    <wsHttpBinding>
            <binding name="WSHttpBinding_Ninjas">
              <security mode="None">
                <transport clientCredentialType="None" />
                <message establishSecurityContext="false" />
              </security>
            </binding>
    ...............................
    
          <wsHttpBinding>
            <binding name="WSHttpBinding_Ninjas">
              <security mode="None" />
            </binding>
    

    But both of them work fine, so I can not reproduce your issue in my side.

    >>but these errors seem to occur in production also (unless the WCF AND the clients we are connecting are using the same process...)

    Do you mean that it works fine if the service and client are in the same PC? But it does not work if the client and service are in the different PCs.

    >>This may be because of either a contract mismatch (mismatched Actions between sender and receiver) or a binding/security mismatch between the sender and the receiver.  Check that sender and receiver have the same contract and the same binding (including security requirements, e.g. Message, Transport, None).

    Based on the error information, it seems that there are some mismatch with the binding/security in your client and service side, so could you please try to post your service and client config file in here? It will help us analyze this issue more clearly.

    Best Regards,
    Amy Peng


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Monday, May 23, 2016 5:17 AM
    Moderator
  • Not quite - it ALWAYS "works"... Just always throws this weird error on startup (before even calling any methods, just the act of connecting to it with WCFTestClient, or on first method call on a real client in prod)... I SUSPECT its something to do with metadata discovery AND also MIGHT be perfectly normal behaviour, but I can't find the WHY of it all.

    vs2015 and vs2013

    File > New > Project > WCF > WCF Service Application

    Replace webconfig with this:

    <?xml version="1.0"?>
    <configuration>
    
      <appSettings>
        <add key="aspnet:UseTaskFriendlySynchronizationContext" value="true" />
      </appSettings>
      <system.web>
        <compilation debug="true" targetFramework="4.5" />
        <httpRuntime targetFramework="4.5"/>
      </system.web>
      <system.serviceModel>
    
    
          <bindings>
          <wsHttpBinding>
            <binding name="WSHttpBinding_Ninjas"
             >
    
              <reliableSession ordered="true"
                               inactivityTimeout="01:10:00"
                               enabled="false" />          
              
              <security mode="None">
                <transport clientCredentialType="None" />
                <message establishSecurityContext="false" />
              </security>
            </binding>
          </wsHttpBinding>
        </bindings>
        <services>
         
          <service name="WcfService1.Service1"  behaviorConfiguration="isitthebehviour" >
            <endpoint address=""
                      binding="wsHttpBinding"
                      bindingConfiguration="WSHttpBinding_Ninjas"
                      contract="WcfService1.IService1">
              <identity>
                <dns value="localhost" />
              </identity>
            </endpoint>
            <endpoint address="mex"
                      binding="mexHttpBinding"
                      contract="IMetadataExchange" />
          </service>
        </services>
        <behaviors>
            <serviceBehaviors>
              <behavior name="isitthebehviour">
                <!-- To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment -->
                <serviceMetadata httpGetEnabled="true" httpsGetEnabled="true" />
                <!-- To receive exception details in faults for debugging purposes, set the value below to true.  Set to false before deployment to avoid disclosing exception information -->
                <serviceDebug includeExceptionDetailInFaults="false" />
                <dataContractSerializer maxItemsInObjectGraph="2147483647" />
              </behavior>
          </serviceBehaviors>
        </behaviors>
        <protocolMapping>
          <add binding="basicHttpsBinding" scheme="https" />
        </protocolMapping>
        <serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" />
    
        <diagnostics wmiProviderEnabled="true">
          <!--if you want to disable the trace source for MessageLogging set these settings to false-->
          <messageLogging logEntireMessage="true"
                          logMalformedMessages="false"
                          logMessagesAtServiceLevel="true"
                          logMessagesAtTransportLevel="true"
                          maxMessagesToLog="3000"
                          maxSizeOfMessageToLog="500000" />
        </diagnostics>
        
      </system.serviceModel>
      <system.webServer>
        <modules runAllManagedModulesForAllRequests="true"/>
        <!--
            To browse web app root directory during debugging, set the value below to true.
            Set to false before deployment to avoid disclosing web app folder information.
          -->
        <directoryBrowse enabled="true"/>
      </system.webServer>
    
      <system.diagnostics>
        <sources>
          <source name="System.ServiceModel"
                  switchValue="Information, ActivityTracing"
                  propagateActivity="true" >
            <listeners>
              <add name="xml" />
            </listeners>
          </source>
          <source name="System.ServiceModel.MessageLogging">
            <listeners>
              <add name="xml" />
            </listeners>
          </source>
          <source name="System.Runtime.Serialization">
            <listeners>
              <add name="xml" />
            </listeners>
          </source>
        </sources>
        <sharedListeners>
          <add name="xml"
               type="System.Diagnostics.XmlWriterTraceListener"
               initializeData="C:\logs\Diagnostics.ServiceModel.svclog"/>
        </sharedListeners>
      </system.diagnostics>
    
    </configuration>
    

    highlight "Service1.svc" file in the solution explorer and press Ctrl+ F5

    WCFTestClient loads up and evaluates the wsdl

    Rightclick on IISExpress icon and Exit and say yes to exit all seriveces

    goto C:\logs\Diagnostics.ServiceModel.svclog

    and you will see the single thrown exception ("process action" about the 4/5th entry in activity in the SVCViewer tool).

    Thanks for taking the time to look into this.


    - sure I'm noJedi but that's no reason to stop trying to make stuff levitate! -

    Wednesday, May 25, 2016 11:10 AM
  • Hello,

    I have followed your steps, but I still can not meet the exception, the following is my svclog:

    Could you please show a screenshot about your svclog file in here?

    Thanks for your understanding.

    Best Regards,
    Amy Peng


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.


    Monday, May 30, 2016 5:24 AM
    Moderator
  • screenshot:

    Aside (related or perhaps not?): thought this was just normal operation but these are always in our OUTPUT window on debugging an WCF application:

    'iisexpress.exe' (CLR v4.0.30319: /LM/W3SVC/98/ROOT-1-131092322062948452): Loaded 'C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Net.Http\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Net.Http.dll'. Symbols loaded.
    A first chance exception of type 'System.ServiceModel.FaultException' occurred in System.ServiceModel.dll
    'iisexpress.exe' (CLR v4.0.30319: /LM/W3SVC/98/ROOT-1-131092322062948452): Loaded 'C:\WINDOWS\Microsoft.Net\assembly\GAC_32\System.Transactions\v4.0_4.0.0.0__b77a5c561934e089\System.Transactions.dll'. Symbols loaded.
    A first chance exception of type 'System.IO.FileNotFoundException' occurred in mscorlib.dll
    'iisexpress.exe' (CLR v4.0.30319: /LM/W3SVC/98/ROOT-1-131092322062948452): Loaded 'Microsoft.GeneratedCode'. 
    'WCFTestClient.exe' (CLR v4.0.30319: WCFTestClient.exe): Loaded 'C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\SMDiagnostics\v4.0_4.0.0.0__b77a5c561934e089\SMDiagnostics.dll'. Symbols loaded.


    - sure I'm noJedi but that's no reason to stop trying to make stuff levitate! -



    • Edited by noJedi Wednesday, June 1, 2016 5:42 AM
    Wednesday, June 1, 2016 5:30 AM
  • Okay I think the issue is environment related... probably something to do with roaming (or not so roaming) profiles.

    watching things with ProcMon for a while I noticed a number of different behaviours using 

    IIS Express vs IIS "full" on localhost as well as different projects behaving slightly differently depending on their setups (in source control or locally or in "\\nwrk\user$\visualstudio12\projects\project" vs "c:\workfolder\project"

    eg: 
    Could not find a part of the path \\nwrk\user$\usrname\Test Client Projects\12.0\CachedConfig

    Seems to have AccessDenied when trying to WRITE (SOMETIMES)... even though according to PROCMON the user context is still "usrname"... which doesn't make a lot of sense to me, but hey... procmon sees all!

    My current theory is that the "core" error (ie the first one on application startup) which is Content Type application/soap+xml; charset=utf-8 was sent to a service expecting text/xml; charset=utf-8

    is actually being thrown by SOME combination of not being able to read/write the correct config "bits" by either the client or the server, and perhaps falling back to somekind of inbuilt WCF "default bindings" of some kind and that's what's throwing the mismatch exceptions...

    not sure how to go about validating this theory... breaking on the initial exception shows me the "local" variables, but I'm not sure where to dig...

    If you have any thoughts on how to work around this issue I'd love to hear them!


    - sure I'm noJedi but that's no reason to stop trying to make stuff levitate! -


    • Edited by noJedi Monday, June 6, 2016 6:55 AM
    Monday, June 6, 2016 5:48 AM
  • Hi noJedi,

    >>A first chance exception of type 'System.ServiceModel.FaultException' occurred in System.ServiceModel.dll

    We do not need to worry about the first change exception, because if we do not meet any others exception, it means that the first change exception has been handled in the end and we can ignore it.

    >>IIS Express vs IIS "full" on localhost as well as different projects behaving slightly differently depending on their setups

    If you use the Local IIS, do you meet the error? It is recommend to use the Local IIS instead of the IIS express, because the Local IIS is the real IIS server. The application works well in the IIS express can not be guarantee to work well in the Local IIS.

    Best Regards,
    Amy Peng


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.



    Monday, June 6, 2016 6:19 AM
    Moderator
  • Hi Amy,

    Unfortunately I get a similar erorr issue under IIS local (full) as with IIS express: as specified in my last post in IIS Local instance you get: Content Type application/soap+xml; charset=utf-8 was sent to a service expecting text/xml; charset=utf-8.  The client and service bindings may be mismatched.

    rather than:cannot be processed at the receiver, due to a ContractFilter mismatch at the EndpointDispatcher. This may be because of either a contract mismatch (mismatched Actions between sender and receiver) or a binding/security mismatch between the sender and the receiver.  Check that sender and receiver have the same contract and the same binding (including security requirements, e.g. Message, Transport, None).

    but its at the same point, doing the same thing:

    throws exception on the first request and then appears to work fine until the server is restarted then you get that same initial error again...


    - sure I'm noJedi but that's no reason to stop trying to make stuff levitate! -

    Monday, June 6, 2016 7:16 AM
  • Additionally:

    If I follow the same process without the WCFTestClient and just build a console app that talks to this service, it behaves similarly but slightly different again:

    Creating the service reference (svcutil) in visual studio, produces a number of errors in the diagnostics file:

    Handling an exception.  Exception details: System.ServiceModel.ProtocolException: There is a problem with the XML that was received from the network. See inner exception for more details. ---> System.Xml.XmlException: The body of the message cannot be read because it is empty.
       --- End of inner exception stack trace ---
       at System.ServiceModel.Channels.HttpPipeline.EnqueueMessageAsyncResult.CompleteParseAndEnqueue(IAsyncResult result)
       at System.ServiceModel.Channels.HttpPipeline.EnqueueMessageAsyncResult.HandleParseIncomingMessage(IAsyncResult result)
       at System.Runtime.AsyncResult.SyncContinue(IAsyncResult result)
       at System.ServiceModel.Channels.HttpPipeline.EmptyHttpPipeline.BeginProcessInboundRequest(ReplyChannelAcceptor replyChannelAcceptor, Action dequeuedCallback, AsyncCallback callback, Object state)
       at System.ServiceModel.Channels.HttpChannelListener`1.HttpContextReceivedAsyncResult`1.ProcessHttpContextAsync()

    then the "client/server mismatch" follows (as above)

    Running the console app operates normally... no exceptions.

    It seems to be only the process of generating the proxy class that is causing the exceptions perhaps? (whcih I think wCFtestclient does dynamically each time it starts up)


    - sure I'm noJedi but that's no reason to stop trying to make stuff levitate! -

    Monday, June 6, 2016 7:46 AM
  • Hmm... okay I've tried this same project on a handful of machines internal to our network and one machine that is a standalone and it works fine (as yours does) on the standalone (no error) and exhibits the same behavior on all other internal machines...

    So I'm not sure what that means becuase its still only seems to affect WCF projects (that I can tell), but appears to be somewhat related to the network/AD/profiles structure of our organisation...

    not sure if that means I should repost this elsewhere or if you have ideas for further troubleshooting, or if (since the error appears to only be affecting metadata and application startup) we should just live with this debuggging and "false" positive error in our logs...?

    thanks again for your time and ideas


    - sure I'm noJedi but that's no reason to stop trying to make stuff levitate! -

    Monday, June 6, 2016 1:35 PM