3

I have a scenario where I need to connect to a secure external soap web service with basic authentication. Normally this isn't a problem, and this works in my local development environment with basicHttpBinding. When the app is deployed it will live in a DMZ and it won't have access to call out to the world. This created a need for a Routing Service on our internal network, and the new routing feature in WCF 4.0 seemed like a good candidate. I got code working to do a call over http to a different external service through the Routing Service as a PoC, and then decided to move into https. I quickly found out that the username credentials from the initial calling app don't get passed along by the Routing Service, so I implemented a custom IEndpointBehavior to add the proper credentials to the Routing Service calls to the external client. Here are my bindings for my client application, as well as my Routing Service.

Client App:

<basicHttpBinding>
    <binding name="SimpleHttp">
        <security mode="Transport">
            <transport clientCredentialType="Basic"/>
        </security>
    </binding>
</basicHttpBinding>

<endpoint address="https://mymachine/routingservice.svc"
          binding="basicHttpBinding" 
          contract="TheContract" 
          name="MyEndpoint" 
          bindingConfiguration="SimpleHttp"/>

Routing Service (Service Endpoint):

<services>
    <service behaviorConfiguration="routingConfiguration"
          name="System.ServiceModel.Routing.RoutingService">
        <endpoint address=""
              binding="basicHttpBinding"
              name="RoutingServiceEndpoint"
              contract="System.ServiceModel.Routing.IRequestReplyRouter"/>
    </service>
</services>

<basicHttpBinding>
    <binding>
        <security mode="Transport">
            <transport clientCredentialType="None"/>
        </security>
    </binding>
</basicHttpBinding>

<serviceBehaviors>
    <behavior name="routingConfiguration">
        <!-- leaving out the filter details for now, since it's match all -->
        <routing filterTableName="filterTable1" />
    </behavior>
</serviceBehaviors>

Routing Service (Client Endpoint):

<client>
    <endpoint name="realDestination"
              address="https://externalwebservice/service/"
              binding="basicHttpBinding"
              bindingConfiguration="otherBasicHttpBinding"
              behaviorConfiguration="CredWriter"
              contract="*" />
</client>

<basicHttpBinding>
    <binding name="otherBasicHttpBinding">
        <security mode="Transport">
            <transport clientCredentialType="Basic"/>
        </security>
    </binding>
</basicHttpBinding>

<endpointBehaviors>
    <behavior name="CredWriter">
        <soapProcessing processMessages="false"/>
        <myCredentialAdder/>
    </behavior>
</endpointBehaviors>

<extensions>
    <behaviorExtensions>
        <add name="myCredentialAdder" type="Assembly Info here."/>
    </behaviorExtensions>
</extensions>

Assuming I'm not missing something obvious, this should all work and go along on it's merry way passing information over https to and fro from client to router to external service and back. (Big assumption)

Instead I was presented with the following exception and stack trace:

System.ServiceModel.CommunicationException: 
An error occurred while receiving the HTTP response to https://mymachine/routingservice.svc. 
This could be due to the service endpoint binding not using the HTTP protocol. 
This could also be due to an HTTP request context being aborted by the server 
(possibly due to the service shutting down). 
See server logs for more details. ---> 
System.Net.WebException: The underlying connection was closed: 
An unexpected error occurred on a receive. ---> 
System.IO.IOException: Unable to read data from the transport connection: 
An existing connection was forcibly closed by the remote host. ---> 
System.Net.Sockets.SocketException: 
An existing connection was forcibly closed by the remote host
   at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
   at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
   --- End of inner exception stack trace ---
   at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
   at System.Net.FixedSizeReader.ReadPacket(Byte[] buffer, Int32 offset, Int32 count)
   at System.Net.Security._SslStream.StartFrameHeader(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security._SslStream.StartReading(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security._SslStream.ProcessRead(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.TlsStream.Read(Byte[] buffer, Int32 offset, Int32 size)
   at System.Net.PooledStream.Read(Byte[] buffer, Int32 offset, Int32 size)
   at System.Net.Connection.SyncRead(HttpWebRequest request, Boolean userRetrievedStream, Boolean probeRead)
   --- End of inner exception stack trace ---
   at System.Net.HttpWebRequest.GetResponse()
   at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
   --- End of inner exception stack trace ---

Server stack trace: 
   at System.ServiceModel.Channels.HttpChannelUtilities.ProcessGetResponseWebException(WebException webException, HttpWebRequest request, HttpAbortReason abortReason)
   at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
   at System.ServiceModel.Channels.RequestChannel.Request(Message message, TimeSpan timeout)
   at System.ServiceModel.Dispatcher.RequestChannelBinder.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)
   //calls to my code were here.

Seeing this I dug into it a little more and piped everything through Fiddler to see what was going on.

My client app calls my IIS hosted routing service over https, and waits. The IIS hosted routing service calls out to the external service. This is where things got weird. There is an https 200, which shows a new 'entity' being returned in a soap envelope, another https 200 which also returns another new 'entity' from the service, and then my call from my client app gets a 504 Gateway Timeout at nearly the exact time the second request comes back from the external service.

This setup gives me a new exception:

System.TimeoutException: The request channel timed out while waiting for a reply after 00:00:59.5720000. 
Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. 
The time allotted to this operation may have been a portion of a longer timeout. 
---> System.TimeoutException: The remote server returned an error: (504) Gateway Timeout. 
---> System.Net.WebException: The remote server returned an error: (504) Gateway Timeout.
   at System.Net.HttpWebRequest.GetResponse()
   at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
   --- End of inner exception stack trace ---
   at System.ServiceModel.Channels.HttpChannelUtilities.ProcessGetResponseWebException(WebException webException, HttpWebRequest request, HttpAbortReason abortReason)
   at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
   at System.ServiceModel.Channels.RequestChannel.Request(Message message, TimeSpan timeout)
   --- End of inner exception stack trace ---

Server stack trace: 
   at System.ServiceModel.Channels.RequestChannel.Request(Message message, TimeSpan timeout)
   at System.ServiceModel.Dispatcher.RequestChannelBinder.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)
   //calls to my code

I made an attempt to up the timeout as the exception suggested, which didn't work, as this was failing in a second or two, and not minutes. So, at this point after scouring the internet looking for examples and other solutions to this problem, I haven't been able to find anything that answers why this is failing, what potential problems could be, or anyone who is attempting to accomplish the same thing.

I'm hoping that you, the community, will be able to find something I haven't yet, have already solved this problem on your own and are willing to share the solution, or can easily spot an issue with my bindings or setup.

Iron Ninja
  • 434
  • 1
  • 3
  • 13
  • Just a quick comment, I read some similar threads which you may have already found that discussed issues with the SSL cert not getting passed on by the router. Maybe check the thumb print and see if it is coming through. – htm11h Jul 10 '14 at 20:49

0 Answers0