locked
Incorrect hostname in EndPoint location in WSDL for a service with multiple bindings and with multipleSiteBindingsEnabled RRS feed

  • Question

  • We have a WCF web service that is exposed through multiple bindings.  The site is  accessed through multiple IP Addresses/Hostnames (internet/intranet).  Some of the bindings use http transport while others use https transport.

    The web application is configured to use .NET 4.0 with multipleSiteBindingsEnabled="true" so that we shouldn't have problems with multiple ip addresses/hostnames.

    What we see is that when the WSDL is accessed using a http based URL (external), the hostnames in the endpoint addresses for http transport based bindings in WSDL are correct (ie, they use the hostname header from the request) while the hostnames in the endpoint addresses for https transport based bindings in the WSDL are incorrect (ie, they do not use the hostname header in the request - they seem to use the hostname from the first available binding in IIS for that scheme and end up with the local machine names/ip addresses in the URL).  

    We could work around by setting the external hostname/ip in the first binding in IIS for the respective scheme, but then WSDLs accessed from intranet clients would have wrong URLS now.

    This happens the other way around as well, ie, when the WSDL is accessed using https, the https based addresses are fine, but http addresses in the WSDL are not correct.

    It looks like hostname header is used only for WSDL endpoint addresses for bindings whose transport matches the transport of the WSDL request.  

    Is this a bug or are we missing something here?

    TIA,
    Madusudanan
    Monday, August 16, 2010 6:12 AM

Answers

All replies

  • Hi,

    Could you share a demo that can reproduce this issue? You can upload the demo to http://skydrive.com and paste download link here.


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. Windows Azure Platform China Blog: http://blogs.msdn.com/azchina/default.aspx
    Wednesday, August 18, 2010 3:14 AM
  • There's nothing specific in code.  It could be just a simple WCF service exposed thorough a BasicHttpBinding with https transport and also another binding with http transport.  The site should be accessible through multiple IP addresses or hostnames or multiple bindings for http/https in IIS.  That is all is required to reproduce the behavior.

     

    Meanwhile saw this post on useRequestHeadersForMetadataAddress behavior.

    Here's a segment from the post

     

     

    As part of this behavior, you can also specify default ports for different schemes (http,https etc..). These default ports come into action in following scenarios:

    • When metadata is accessed over http, all http based URIs are substitued with the Hostname and host port from the Host header
    • All https based URIs picks the default port registered against https scheme
    • Similarly when metadata is accessed over https, all https URIs pick up the host and port from the host header and http based URIs used the default port registered against http scheme

     

     

    This describes the behavior that we observe.  

    We had not used this behavior and upon some digging into the ServiceHostingEnvironment code, found this piece

     

    if (this.multipleSiteBindingsEnabled && (base2.Description.Behaviors.Find<UseRequestHeadersForMetadataAddressBehavior>() == null))

    {

    base2.Description.Behaviors.Add(new UseRequestHeadersForMetadataAddressBehavior());

    }

     

    When multipleSiteBindings is enabled, the default ServiceHost addes the UseRequestHeadersForMetadataAddressBehavior.

     

    This probably explains the behavior.  It is understandable that the UseRequestHeadersForMetadataAddress Behavior requires you to specify port hints for transport schemes, so that for schemes other than the one through which the service WSDL is accessed, it could use the port hint to pick up the correct binding/hostname and return the correct URL.

    However, when picking up the host name from the binding, why does it not use the incoming hostname header as another hint to pick the correct host name - if there is a binding for that scheme/port that allows binding for all host names (binding with a blank hostname) or if there is a binding with a hostname that matches the incoming (wsdl request) hostname. Will that not be a more acceptable URL in most cases than picking up the default host name (mostly an internal name/ip), which is more likely to be incorrect.

    Is there someway this can be handled?

    TIA,

    Madusudanan

    Wednesday, August 18, 2010 5:08 AM
  • Hi,

    I've reproduced this issue and opened a ticket in:

    https://connect.microsoft.com/wcf/feedback/details/587418/the-host-name-of-endpoint-url-in-wsdl-is-better-to-keep-consistant-for-all-endpoints-when-using-httpget-httpsget-to-fetch-metadata

    Please vote and leave your comments there. Our dedicated engineer will work with you on this issue.


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. Windows Azure Platform China Blog: http://blogs.msdn.com/azchina/default.aspx
    Thursday, August 19, 2010 9:29 AM
  • You may want to check the bindings of the web site hosting your wcf service. By default the host name for https is undefined. I found your problem was fixed by editing the binding for https and entering a host name. You can edit the hostname using:

    %systemdrive%inetpub\adminscripts\adsutil.vbs set /w3svc/<id>/SecureBindings ":443:<hostname>"

     

    Thursday, September 9, 2010 2:41 PM
  • Hi there,

    The URL referenced above no longer exists. I'm seeing the exact same issue (.NET 4.0, IIS 7.5) - is there a fix for this, or a solution other than creating a separate site for each binding?

    Friday, August 25, 2017 1:54 PM
  • Hi there,

    The URL referenced above no longer exists. I'm seeing the exact same issue (.NET 4.0, IIS 7.5) - is there a fix for this, or a solution other than creating a separate site for each binding?

    Monday, September 11, 2017 9:03 AM