Specifies how the host name should be used in URI comparisons when dispatching an incoming message to a service endpoint.
Assembly: System.ServiceModel (in System.ServiceModel.dll)
The value is used to specify the URI matching rules used by transports such as HTTP, Net.Tcp, and Net.Pipe when dispatching incoming messages. Configure the value of the for a standard binding using one of the preceding transports, such as BasicHttpBinding, using the corresponding HostNameComparisonMode property. Configure the value of the for a binding element using one of the preceding transports, such as HttpTransportBindingElement, using the corresponding HostNameComparisonMode property.
Each value of the corresponds to a specific type of matching rule. The sequence of matching rules attempted is always ordered as follows:
The first value, StrongWildcard, ignores the host name when matching and it takes the highest precedence of the three different matching modes. It is the default value for a WCF system-provided binding or binding element. This indicates that a service endpoint can be reached using any valid host name. For example, if MyService is hosted using http://localhost/MyService, it is still reachable using http://www.adatum.com/MyService because the (presumably valid) host name, "adatum.com", is ignored. Note that the port is a wildcard here as well.
The second value, Exact, requires that an exact match is found with the URI specified, including the hostname, if no strong match is found. This mode, for example, does not perform equivalence between short hostnames and fully-qualified domain names. This allows hostnames to be used as match criteria in the scenarios where multiple hosts are assigned a single IP address and it enables different services to be hosted on the same machine with distinct endpoints. Note that the port is a wildcard here as well.
The third value, WeakWildcard, matches by ignoring the hostname if no strong or exact match was found. The behavior is the same as for other than the order of matching: it runs after the strong and exact bindings have been tried.
These values have no effect when used inside of the Internet Information Services (IIS) or Windows Process Activation Service (WAS) hosting environment. In those cases, WCF uses whatever hostname comparison mode is provided by the IIS Web Site hosting the WCF services.
The following is an example of how to set StrongWildcard value in a service side configuration file.
<system.serviceModel> <services> <service name="UE.Samples.HelloService" behaviorConfiguration="HelloServiceBehavior"> <endpoint address="http://localhost:8000/UESamples/HelloService" binding="basicHttpBinding" bindingConfiguration="Binding1" contract="UE.Samples.ISayHello" /> <endpoint contract="IMetadataExchange" binding="mexHttpBinding" address="mex" /> </service> </services> <bindings> <basicHttpBinding> <binding name="Binding1" hostNameComparisonMode="StrongWildcard"> </binding> </basicHttpBinding> </bindings> <behaviors> <serviceBehaviors> <behavior name="HelloServiceBehavior"> <serviceMetadata httpGetEnabled="true" /> </behavior> </serviceBehaviors> </behaviors> </system.serviceModel>
Here is a basic service and client that use the preceding configuration file.
// Open up a channel factory on a client application. ChannelFactory<ISayHello> factory = new ChannelFactory<ISayHello>("BasicHttpBinding_ISayHello"); // Both of these contracts work (provided both hostnames are valid) because // the binding configuration is set to hostNameComparisonMode="StrongWildcard". ISayHello channel = factory.CreateChannel(new EndpointAddress("http://localhost:8000/UESamples/HelloService")); ISayHello channel2 = factory.CreateChannel(new EndpointAddress("http://machineName/UESamples/HelloService")); Console.WriteLine(channel.SayHello()); Console.WriteLine(); Console.WriteLine("Press <ENTER> to terminate client."); Console.ReadLine();
Windows 8.1, Windows Server 2012 R2, Windows 8, Windows Server 2012, Windows 7, Windows Vista SP2, Windows Server 2008 (Server Core Role not supported), Windows Server 2008 R2 (Server Core Role supported with SP1 or later; Itanium not supported)
The .NET Framework does not support all versions of every platform. For a list of the supported versions, see .NET Framework System Requirements.