none
Configuring IIS7 for a net.tcp WCF hosted service with multiple websites and host headers RRS feed

  • Question

  • I'm hosting multiple WCF services under IIS7 using net.tcp binding.

    Each site is configured to use host headers, and I added the net.tcp binding, although I'm using 9001 instead of 808.  All of the services are on the same machine using the same IP address.

    For example, I have two identical services with the same ip address that have host headers of:

    foo.example.com
    bar.example.com

    The problem I have arises when I try to connect to the service at bar.example.com.  It connects to foo.example.com instead.

    I solved the problem by changing the net.tcp binding information for each site by putting in:

    9001:foo.example.com
    9001:bar.example.com

    instead of using the wildcard

    9001:*

    I have two questions.  First of all I'm looking for some documentation on the syntax for binding information, especially wildcards.  The second question is WHY do I need to specify the host header on the net.tcp binding since the site is configured for host headers already.  Is this because the host header information is relevant for HTTP only?  I don't recall ever having to do anything special for host headers for HTTPS....

    Thanks.
    Monday, January 4, 2010 2:05 PM

Answers

  • Here are some articles describing hostname comparison modes in http, but similiar semantics are also applied to net.tcp.  You can specify either weak wildcard (*), strong wildcard (+), or explicit (ip or hostname) in your binding information. 

    http://kennyw.com/work/indigo/109
    http://msdn.microsoft.com/en-us/library/aa364698(VS.85).aspx


    You are correct that the host information is only relevant to http.  Each transport type (net.tcp, net.pipe, etc ..)  has their own binding information and format that needs to be specified. 

    I believe you never ran into this issue with https because the host information is specified in the certificate, so you never have to specify it in the binding info.

    Cheers,
      Lars
    Wednesday, January 6, 2010 1:51 AM

All replies

  • Here are some articles describing hostname comparison modes in http, but similiar semantics are also applied to net.tcp.  You can specify either weak wildcard (*), strong wildcard (+), or explicit (ip or hostname) in your binding information. 

    http://kennyw.com/work/indigo/109
    http://msdn.microsoft.com/en-us/library/aa364698(VS.85).aspx


    You are correct that the host information is only relevant to http.  Each transport type (net.tcp, net.pipe, etc ..)  has their own binding information and format that needs to be specified. 

    I believe you never ran into this issue with https because the host information is specified in the certificate, so you never have to specify it in the binding info.

    Cheers,
      Lars
    Wednesday, January 6, 2010 1:51 AM
  • Hi Fasttimes,

    Please let me how you configure the service to listen the same IP address with port-sharing in your scenario.

    Whether you can share one physical address between multiple endpoints in one WCF service to implement your requirement like the following self-Host sample so as to reduce the number of exposed services.

     <system.serviceModel>
        <services>
          <service
              name="ConsoleApplication1.SimpleService"
              behaviorConfiguration="BehaviorConfiguration">
            <host>
              <baseAddresses>
                <add baseAddress="net.tcp://localhost/MetadataSample"/>
                <add baseAddress="http://localhost/MetadataSample"/>
              </baseAddresses>
            </host>
            <endpoint address="Mex"
                      binding="mexTcpBinding"
                      bindingConfiguration=""
                      name="MexEndpoint"
                      contract="IMetadataExchange" />
            <endpoint
              address="urn:Foo"   
              listenUri=""
              binding="netTcpBinding"
              bindingConfiguration="BindingConfiguration"
              name="TcpBinding"
              contract="ConsoleApplication1.ISimpleService1" />
            <endpoint
              address="urn:Bar"                             
              listenUri=""
              binding="netTcpBinding"
              bindingConfiguration="BindingConfiguration"
              name="TcpBinding"
              contract="ConsoleApplication1.ISimpleService2" />       
          </service>
        </services>
        <behaviors>
          <serviceBehaviors>
            <behavior name="BehaviorConfiguration">
              <serviceMetadata httpGetEnabled="true" />
              <serviceDebug includeExceptionDetailInFaults="true" />
            </behavior>
          </serviceBehaviors>
        </behaviors>
        <bindings>
          <netTcpBinding>
            <binding name="BindingConfiguration">
            </binding>
          </netTcpBinding>
        </bindings>
      </system.serviceModel>

    Generally, we will use the address attribute to specify the URL on which the endpoint will listen on. However, this address is actually a logical address and WCF runtime will use it as physical address also if we haven’t explicitly provide a physical address. The listenUri , on the contrary, represents the physical transport address the service endpoint listens on.

    Also, for the endpoints that share the same physical address, they will share the same service dispatcher and channel stack. Then, how does the WCF runtime differentiate those operation requests when there are multiple endpoints listening on a single physical address? The answer is WCF runtime will try to resolve the request target by the combination of two parts below:
    •    The Service/Operation Contract
    •    The logical address specified via address attribute

    Therefore, the dispatcher /channel stack can correctly redirect the requests to the corresponding endpoint even if we supply the identical value for both logical and physical address.

    Best regards,
    Riquel
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Wednesday, January 6, 2010 6:39 AM
    Moderator