none
configuring site bindings with a custom header

    Question

  • Hi,
    I have the same problem when connecting to IIS worker process instance.


    Some background:
    I have created default web app and cloud project in a new solution. In Azure config file I set hostHeader="aztest3.local.domain". 
    Endpoint has port="8011". In hosts file I have mapped aztest3.local.domain to 127.0.0.1.

    When I run debug of Azure project then I see that on IIS has been created new Website with binding to port 5120(??? !!!) and aztest3.local.domain on host header.
    Azure Compute Emulator says the service endpoint url is http:/*:8011 and ip address is 127.0.0.1:8011. The browser (IE) has been called for http://127.0.0.1:8011/

    Trying to browse it manually for url http://127.0.0.1:5020/Default.aspx (in reality to existing web app on IIS) failed also.
    Trying to browse it manually for url http://aztest3.local.domain:5020/Default.aspx succeeded.

    Without using hostHeader everything seems to be working ok (I mean website binding contains proper endpoint port).

     

    Does anybody know how to configure hostHeader properly?
    Production deployment on Azure also doesn't map host header to port properly (in reality I have to use port number with my custom domain :( so it doesn't work)

    I did tests on Win Srv 2008 R2 with VStudio 2010 (Ultimate) and Azure SDK 1.3. VStudio has SP1Rel installed also...

     

    Regards,
    Alek

    • Edited by Alex Stankiewicz Wednesday, December 22, 2010 1:18 PM small change in sentence
    • Split by Steve Marx Wednesday, December 22, 2010 7:37 PM separate question
    Wednesday, December 22, 2010 1:17 PM

Answers

  • Are you just talking about how VS opens IE?  What's wrong with just typing it in?

    There's nothing in the tooling to automatically open IE to a destination other than 127.0.0.1 with the port specified in your HTTP endpoint.

    Wednesday, December 22, 2010 11:57 PM
  • I think I found some solution (stupid, but for now it's ok).

    In binding section I provided bindings with hostHeader definitions (attributes) for all the sites.
    But on one site only (that one that I want to debug and attach to it automatically with debugger) has additional binding configuration, but without hostHeader definition.

    This way, when I start debugger on dev machine, VStudio calls IE with 127.0.0.1 and it will be automatically (and properly) resolved to WebApp on local IIS.
    Such configuration can be published on Azure without changes also, because there proper host names will be provided in http request and IIS resolves WebApps correctly again.

    So some config file can be like below:

     

    <WebRole name="WIF-Security.Web">
     <Sites>
     <Site name="WebSecTest" physicalDirectory="..\WIF-Security-ACS2.Web">
     <Bindings>
      <Binding name="Development-WebSecTestHTTPS" endpointName="EndpointHTTPS" /><!-- It's important -->
      <Binding name="Production-WebSecTestHTTPS" endpointName="EndpointHTTPS" hostHeader="aztest1.domain.eu" />
     </Bindings>
     </Site>
     <Site name="WebApp2" physicalDirectory="..\WIF-TestAPP-2">
     <Bindings>
      <Binding name="Production-WebApp2" endpointName="EndpointHTTPS" hostHeader="aztest2.domain.eu" />
     </Bindings>
     </Site>
     </Sites>
     <Endpoints>
     <InputEndpoint name="EndpointHTTPS" protocol="https" port="443" certificate="Certek" />
     </Endpoints>
    

     

    BTW:

    Nothing is wrong doing things manually (typing addresses on IE address bar to start debugging, writing different config files manually in situation
    when they could be generated by some tools and so on).

    Don't get me wrong. I'm just not to big fan of using emacs and command line compiler :)
    Such stuff like using host header value on IE startup is easy to provide (at least it's not a rocket science) :)

    Thursday, December 23, 2010 10:14 AM

All replies

  • Hi,
    I have the problem when connecting to IIS worker process instance...


    Some background:
    I have created default web app and cloud project in a new solution. In Azure config file I set hostHeader="aztest3.local.domain". 
    Endpoint has port="8011". In hosts file I have mapped aztest3.local.domain to 127.0.0.1.

    When I run debug of Azure project then I see that on IIS has been created new Website with binding to port 5120(??? !!!) and aztest3.local.domain on host header.
    Azure Compute Emulator says the service endpoint url is http://*:8011 and ip address is 127.0.0.1:8011. The browser (IE) has been called for http://127.0.0.1:8011/

    Trying to browse it manually for url http://127.0.0.1:5020/Default.aspx (in reality to existing web app on IIS) failed also.
    Trying to browse it manually for url http://aztest3.local.domain:5020/Default.aspx succeeded.

    Without using hostHeader everything seems to be working ok (I mean website binding contains proper endpoint port).

    After machine restart it creates binding on IIS with value 5100 instead of 5020 (like previously). Strange ...

    Does anybody know how to configure hostHeader properly?
    Production deployment on Azure also doesn't map host header to port properly (in reality I have to use port number with my custom domain :( so it doesn't work)

    I did tests on Win Srv 2008 R2 with VStudio 2010 (Ultimate) and Azure SDK 1.3. VStudio has SP1Rel installed also...

    BTW:
    I was trying to use hostHeader on https binding also, but without success also of course. Is there any chance it can work?
    I know we can use such syntax like below to assign host header for https (ssl) type binding, but it's not appropriate for Azure of course (beause of dynamic node contruction/removal):
    appcmd set site /site.name:"<IISSiteName>" /+bindings.protocol='https',bindingInformation='*:443:<hostHeaderValue>']

    Regards,
    Alek

    • Edited by Alex Stankiewicz Wednesday, December 22, 2010 3:52 PM added port
    • Merged by Steve Marx Wednesday, December 22, 2010 7:43 PM duplicate
    Wednesday, December 22, 2010 1:22 PM
  • The fact that the web site is bound to a port like 5020 is expected.  The load balancer will listen on port 8011 and forward traffic.  From your setup, I would expect http://aztest3.local.domain:8011 is what you want to use.  Does that not work?

    By the way, if you want to control the local port on the VM (what you saw as 5020 running locally), this is possible with SDK 1.3.  Just add localPort="8011" to the endpoint declaration in ServiceDefiinition.csdef.  I think that means you can't test multiple instances locally, though, since they'd all be trying to bind to the same port.

    Wednesday, December 22, 2010 7:28 PM
  • Wow, you posted this question in lots of places.  At least here on the MSDN forum I can merge them... doing so now...
    Wednesday, December 22, 2010 7:35 PM
  • Hi Steve,

    first of all thanks for the answer :)

    As I wrote I was trying to connect to the website created dynamically by dev app fabric on IIS (through 127.0.0.1:8011), but it failed. 
    No any (local) load balancer has forwarded the call to port 5020 (binding on IIS). The service is configured to start as a single instance.
    Maybe the issue is that in hosts file I provided localhost instead of domain name of server (or temporary IP from dhcp)?

    Anyway I was unable to connect to port of my endpoint (from Azure config file) using IE. Request for url with IP=127.0.0.1 was also rejected by IIS (custom host header on IIS was set to aztest3.local.domain). The only option that was working in my case was http://aztest3.local.domain:5020
    (I will try it with 8011 port tomorrow). 

    What surprised me, was the call of IE with IP 127.0.01 in address bar instead of aztest3.local.domain (call constructed dynamically by pressing F5 on VStudio). How to call IE with aztest3 name in address bar after pressing F5?

    When IIS see such call there is no chance to process host header aztest3 simply because there is no such host name in url... :(

    As I wrote previously, using hostHeader with http binding on production Azure deployment doesn't work as expected also.

    I configured CNAME record on my provider to point out proper dns name of my production deployment, but when I call that app using my custom domain, the browser goes to proper IP, but without providing the port in url there is no chance to connect to the app on Azure.

    So call like http://myapp.somedomain.com fails, but http://myapp.somedomain.com:8011 works as expected... By me hostHeader on Azure doesn't work :(

    hostHeader is set to myapp.somedomain.com on binding of course.

     

    What can be wrong? Do you need more info/test results to help me on this issue?

     

    Regards,

    Alek

    Wednesday, December 22, 2010 8:34 PM
  • Locally, the SDK doesn't have intelligence to start IE with one of the hosts you used in your site binding, so you'll need to manually browse to aztest3.local.domain.  (In general, you would usually have several host bindings, otherwise there's not much of a point to using them, so there's no way to guess which one you want to browse to.)

    In the cloud, you're saying http://myapp.somedomain.com:8011 works, so what's the problem?  It seems like things are working properly.

    I didn't understand "but when I call that app using my custom domain, the browser goes to proper IP, but without providing the port in url there is no chance to connect to the app on Azure."  What exactly are you typing into the address bar, and what's happening?

    Wednesday, December 22, 2010 9:07 PM
  • Ok. I was expecting when I start debug session and VStudio starts IE with address of some app it will be aztest3.local.domain instead of 127.0.0.1.
    I had such assumption because port has been determined properly from the binding, but host header has been ignored.
    Maybe there is some switch to force usage of hostheader from binding instead of IP?

    Wednesday, December 22, 2010 11:09 PM
  • Are you just talking about how VS opens IE?  What's wrong with just typing it in?

    There's nothing in the tooling to automatically open IE to a destination other than 127.0.0.1 with the port specified in your HTTP endpoint.

    Wednesday, December 22, 2010 11:57 PM
  • I think I found some solution (stupid, but for now it's ok).

    In binding section I provided bindings with hostHeader definitions (attributes) for all the sites.
    But on one site only (that one that I want to debug and attach to it automatically with debugger) has additional binding configuration, but without hostHeader definition.

    This way, when I start debugger on dev machine, VStudio calls IE with 127.0.0.1 and it will be automatically (and properly) resolved to WebApp on local IIS.
    Such configuration can be published on Azure without changes also, because there proper host names will be provided in http request and IIS resolves WebApps correctly again.

    So some config file can be like below:

     

    <WebRole name="WIF-Security.Web">
     <Sites>
     <Site name="WebSecTest" physicalDirectory="..\WIF-Security-ACS2.Web">
     <Bindings>
      <Binding name="Development-WebSecTestHTTPS" endpointName="EndpointHTTPS" /><!-- It's important -->
      <Binding name="Production-WebSecTestHTTPS" endpointName="EndpointHTTPS" hostHeader="aztest1.domain.eu" />
     </Bindings>
     </Site>
     <Site name="WebApp2" physicalDirectory="..\WIF-TestAPP-2">
     <Bindings>
      <Binding name="Production-WebApp2" endpointName="EndpointHTTPS" hostHeader="aztest2.domain.eu" />
     </Bindings>
     </Site>
     </Sites>
     <Endpoints>
     <InputEndpoint name="EndpointHTTPS" protocol="https" port="443" certificate="Certek" />
     </Endpoints>
    

     

    BTW:

    Nothing is wrong doing things manually (typing addresses on IE address bar to start debugging, writing different config files manually in situation
    when they could be generated by some tools and so on).

    Don't get me wrong. I'm just not to big fan of using emacs and command line compiler :)
    Such stuff like using host header value on IE startup is easy to provide (at least it's not a rocket science) :)

    Thursday, December 23, 2010 10:14 AM
  • Alex, I like you find it really annoying to have to change the url every single time I debug my app locally in Azure Emulator. It might be easy enough to change the url manually, but when you also have to wait for the emulator to fire up, the browser to fire up etc, maybe just to check a few lines of code you've changed every little counts to make things a bit more RAD.

    I don't know why Steve Marx doesn't see why having to do the same repetitive task 1500 times a day would be frustrating when it could (should) be automated. (sorry - maybe he does, as he certainly didn't seem to like having to post the same answer in two places ;)

    Anyhow, I couldn't get your solution to work, and due to the constraints of my solution, my local setup, etc, I eventually opted for a very nasty, but also very quick and easy hack / fix.

    I added some simple javascript to my main master page that checks for the presence of the localhost address in the window.location, and redirects the page to the proper url I want to debug on

    e.g. 

    </div>

    <script>

    DirectToDebugApp();

    </script>

    </body>

     

     

    function DirectToDebugApp() {

        if (window.location.toString().contains("127.0.0.1")) {

            RedirectPage(String_Format("http://domainnametodebugon.com:{0}", [location.port]));

        }

    }

     

     

    n.b. contains() is a customisation to the String.prototype I use, and String_Format() is also a custom method I use to emulate c#.

    Hurrah hours of dev time saved !!! 

    Hope that helps someone else.

     

    Saturday, February 12, 2011 9:22 AM
  • Hi,
    nice workaround :) !

    You can't run your code through my config file (probably) because of absence of some names in hosts file.
    The file is located here in Windows 7 and in Windows Server 2008:
    C:\Windows\System32\drivers\etc


    I noticed it when I was configuring different project and then I recalled that because of domain name absence in hosts file ("local DNS") it's incorrectly resolved.
    So fix is probably easy: add your "public" dns host names to your local host file to replace resolver result/behavior. It should be something like this:

    127.0.0.1     domainnametodebugon.com

    This way you domainnametodebugon.com will be redirected to 127.0.0.1
    I hope it resolves your issue with config provided by me :)

    Monday, February 14, 2011 8:11 AM
  • Alex, I like you find it really annoying to have to change the url every single time I debug my app locally in Azure Emulator. It might be easy enough to change the url manually, but when you also have to wait for the emulator to fire up, the browser to fire up etc, maybe just to check a few lines of code you've changed every little counts to make things a bit more RAD.

    I don't know why Steve Marx doesn't see why having to do the same repetitive task 1500 times a day would be frustrating when it could (should) be automated. (sorry - maybe he does, as he certainly didn't seem to like having to post the same answer in two places ;)

    I couldn't have said this any better. As of May 2012 this still seems to be a problem, and it's ridiculous to expect us to manually type the host headers in every time we hit F5, just as it would be to expect the same thing for standard (non-Azure) web development within VS. Thanks for the javascript redirect idea, good one.
    Friday, May 11, 2012 5:03 PM