Question

Trying to migrate a web application to be used on Azure. The application works great on standard IIS. When using the Azure emulator to test the web application locally, all postbacks result in

Bad Request – Invalid Hostname

HTTP Error 400. The request hostname is invalid.

I’m at a loss of where to look to gather more information. So far I’ve tried:

• Debugging the application. I can verify breakpoints are hit on initial page load, so debugging is definitely working. When causing a postback, no exception is caught by the debugger.

• Looking in the Event Viewer. There’s literally no logs for this problem in either the Application or System Windows logs.

• Checked out the IIS bindings created by the Azure emulator. I noticed that that there’s bindings created on IP address 127.255.0.0, port 8081. If I change this IP address binding to be 127.0.0.1, postbacks work correctly again. This is why I believe the problem is a result of load balancing: if I bypass the load balancer, we’re in business again. Obviously this isn’t a permanent solution.

I’m not sure where to look at this point: I’m having a difficult time finding information about the load balancer or how it works. Is there somewhere I can look for more information? This web application must be doing something specific to cause the error, even though it appears no exceptions are being thrown. What might cause this?

Answer 1

I found a link that pretty much explains it all: http://social.msdn.microsoft.com/Forums/en-AU/windowsazuredevelopment/thread/87c729e8-094c-4578-b9d1-9c8ff7311577 .

In the application just Request.Url was being used to determine the actual page the user is on and then it could be used to build URLs to route them elsewhere. This worked great in just IIS because someone who viewed the web application at http://somedomain.com/page.aspx?var=1 would have this set to the Request.Url parameter. In terms of my localhost example, this would simply be http://127.0.0.1:8080/page.aspx?var=1.

With Azure, the load balancer is actually the one set to listen to this IP on this port. The load balancer then transfers the request to one of the instances, running on a different port. This causes the Request.Url property to be http://127.0.0.1:8081/page.aspx?var=1. This property was then being used to build URLs to be used in Server.Transfer calls, which resulted in bad requests because they should be built upon the original port 8080, not this specific instance’s port, 8081.

I dove into the decompiled code, trying to best mimic the Request.Url property, but have it map to the original request. The code for Request.Url is a little weird:

public Uri Url {
  get {
    if (this._url == (Uri) null && this._wr != null) {
      string s = this.QueryStringText;
      if (!string.IsNullOrEmpty(s))
        s = "?" + HttpEncoder.CollapsePercentUFromStringInternal(s, this.QueryStringEncoding);
      if (AppSettings.UseHostHeaderForRequestUrl) {
        string knownRequestHeader = this._wr.GetKnownRequestHeader(28);
        try {
          if (!string.IsNullOrEmpty(knownRequestHeader))
            this._url = new Uri(this._wr.GetProtocol() + "://" + knownRequestHeader + this.Path + s);
        }
        catch (UriFormatException ex){}
      }
      if (this._url == (Uri) null) {
        string str = this._wr.GetServerName();
        if (str.IndexOf(':') >= 0 && (int) str[0] != 91)
          str = "[" + str + "]";
        this._url = new Uri(this._wr.GetProtocol() + "://" + str + ":" + this._wr.GetLocalPortAsString() + this.Path + s);
      }
    }
    return this._url;
  }
}

I can’t find any information on HttpWorkerRequest.GetKnownRequestHeader(28). MSDN Isn’t helpful.

Returns the standard HTTP request header that corresponds to the specified index.

Okay. What are the indexes? The decompiled code for this method just returns (string)null. So really, I guess this does nothing.

Anyway. I ended up replacing the property with this:

new Uri( HttpContext.Current.Request.Url.Scheme + "://" + HttpContext.Current.Request.Headers[ "Host" ] + HttpContext.Current.Request.Url.PathAndQuery )

HttpContext.Current.Request.Headers[ "Host" ] returns the original request hostname:port. Host is a required header, so this should be good. Hopefully using this provides all of the consistency of the previous behavior, while allowing for the web application to function on Azure.