none
Windows Azure SDK v1.5 - Dev Fabric Emulator - problem with Request.Url.Port

    Question

  • Hi all,

     

    Congratulations on releasing V1.5 of the Azure SDK. 

    I have run into a problem with Request.Url.Port in an Azure Web Role. While the application launches on port 81 and works successfully, if you in code behind use the Request.Url.Port property the return value is 82. Trying to access the application port 82 results in a HTTP 400 Bad Request. 

    This suggests something is running on port 82, but I can't get to it via 127.0.0.1:82.

    Example UI using Request.Url.Port:

    Reproduction code:

    https://skydrive.live.com/?cid=29616fba801f9a8d&sc=documents&uc=2&id=29616FBA801F9A8D%21127#

     

    Thanks again guys,

    Andy

     

     


    http://blog.bareweb.eu
    • Edited by Andy Cross Thursday, September 15, 2011 7:04 PM didn't say thanks ;-)
    Thursday, September 15, 2011 7:03 PM

Answers

  • A couple of workarounds for me might be the following:

    RoleEnvironment.CurrentRoleInstance.InstanceEndpoints.First().Value.IPEndpoint
    

    (obviously this only works if you want the first instance endpoint for your role).

    This gives the value "127.255.0.0:82".

    To find the requesting URL port fragment

    Request.Headers["Host"];
    

    This gives the value: ""127.0.0.1:81";

    Thanks to Fernando to tipping me off to what was happening.

    Regards

    Andy

     


    http://blog.bareweb.eu
    Friday, September 16, 2011 6:38 AM

All replies

  • Up until the previous release of the SDK, the compute emulator load balancer listened on an "external" address of 127.0.0.1 and port 8X (the first port available port after 80), while each web role instance was bound to the same "internal" IP address, 127.0.0.1, but on different ports (usually 5100, 5101, 5102, etc..).

    In this release, the compute emulator load balancer still listens at 127.0.0.1 and port 8X, but each role instance is now bound to a different IP address (127.255.0.1, 127.255.0.2, 127.255.0.3, etc..) and they use the same port (82).

    The value you obtain from Request.Url.Port is the internal address of the instance. So if you wanted to hit a specific instance, bypassing the load balancer, you can access it using http://127.255.0.x:82.

     

     

    Friday, September 16, 2011 5:58 AM
  • Hi Fernando,

    Thanks for the explanation. I'd love to see some documentation for this.

    I've been looking through IIS and my experience matches the above. Whilst the Emulator load balancer is available on 127.0.0.1:81, the IIS site has been configured by the Azure SDK on role launch to use http://127.255.0.0:82/

    There is a potential for a workaround here in my application, but it won't solve the fact that now Request.Url is inconsistent. 

    Request.Url should either be "http://127.0.0.1:81" or more correctly "http://127.255.0.0:82". As it is, the example application shows "http://127.0.0.1:82", which is the load balancers' IP address but the role instance port. 

    Andy


    http://blog.bareweb.eu
    Friday, September 16, 2011 6:11 AM
  • A couple of workarounds for me might be the following:

    RoleEnvironment.CurrentRoleInstance.InstanceEndpoints.First().Value.IPEndpoint
    

    (obviously this only works if you want the first instance endpoint for your role).

    This gives the value "127.255.0.0:82".

    To find the requesting URL port fragment

    Request.Headers["Host"];
    

    This gives the value: ""127.0.0.1:81";

    Thanks to Fernando to tipping me off to what was happening.

    Regards

    Andy

     


    http://blog.bareweb.eu
    Friday, September 16, 2011 6:38 AM
  • Hi Andy,

    You should be able to retrieve the internal address with the following code:

     Request["LOCAL_ADDR"] + ":" + Request["SERVER_PORT"];

    This is the address on which the request came in.

    Friday, September 16, 2011 11:36 AM
  • Hi Andy,

    I find the

    RoleEnvironment.CurrentRoleInstance.InstanceEndpoints.First().Value.IPEndpoint

    very useful. Thanks for posting that.

    I need it in order to force IIS to require client certificates for SSL connections and do it with two steps:

    First delete existing binding:

    netsh http delete sslcert ipport=127.255.0.0:8081

    Second: Add new (same) binding, but with clientcertnegotiation=enable.

    Netsh http add sslcert ipport=127.255.0.0:8081 certhash=4d12345663d9b2aa6d200fc1a04b5d30212ea33e appid={00112233-4455-6677-8899-AABBCCDDEEFF} clientcertnegotiation=enable

    Both are called from a startup task with System.Diagnostics.Process.Start(...).


    • Edited by Hu Ha Tuesday, February 05, 2013 8:56 AM
    Tuesday, February 05, 2013 8:55 AM