Are que getting null or empty with some Request.ServerVariables
When you convert your ASP application to run on Windows Azure it is a good
to put attention to the methods that are used to get the user IP Address.
Normally the recommendation will be to use Request.UserHostAddress however
our friend Alex has found that this property can return null or empty.
After some research Alex found that there are several scenarios under which
you must check both the REMOTE_ADDR and the HTTP_X_FORWARD_FOR server variables:
More info:
http://forums.asp.net/t/1138908.aspx and
http://meatballwiki.org/wiki/AnonymousProxy
A possible code snipped that can provide a value for the client address can be:
public static string ReturnIP()
{
var request = System.Web.HttpContext.Current.Request;
var ServerVariables_HTTP_X_FORWARDED_FOR = (String)request.ServerVariables["HTTP_X_FORWARDED_FOR"];
var ServerVariables_REMOTE_ADDR = (String)request.ServerVariables["REMOTE_ADDR"];
string ip = "127.0.0.1";
if (!string.IsNullOrEmpty(ServerVariables_HTTP_X_FORWARDED_FOR) &&
!ServerVariables_HTTP_X_FORWARDED_FOR.ToLower().Contains("unknown"))
{
ServerVariables_HTTP_X_FORWARDED_FOR = ServerVariables_HTTP_X_FORWARDED_FOR.Trim();
string[] ipRange = ServerVariables_HTTP_X_FORWARDED_FOR.Split(',');
ip = ipRange[0];
}
else if (!string.IsNullOrEmpty(ServerVariables_REMOTE_ADDR))
{
ServerVariables_REMOTE_ADDR = ServerVariables_REMOTE_ADDR.Trim();
ip = ServerVariables_REMOTE_ADDR;
}
return ip;
}
In the previous code the HTTP_X_FORWARDED_FOR value is examined first and if it is not null or unknown then ip address of the client
is gotten from there.
Recently while we were performing the migration of a blog engine in ASP.NET to Azure we had to deal with some issues with
the differences between IIS6 and IIS7.
Windows Azure Web Roles, use IIS7, with Integrated Pipeline mode and that is a breaking change for some ASP.NET sites.
The are at least two main changes:
First is for HTTP modules and handlers.(This info was taken from: http://arcware.net/use-a-single-web-config-for-iis6-and-iis7/)
" For IIS6, they were configured in the <system.web> section, as such:
<httpModules>
<add name="..." type="..." />
<add name="..." type="..." />
<add name="..." type="..." />
</httpModules>
<httpHandlers>
<add verb="..." path="..." type="..." />
<add verb="..." path="..." type="..." />
</httpHandlers>
However, to get these to work in IIS7 you must *move them* from the <system.web> section to the new <system.webServer> section, which is what IIS7 requires when running in Integrated Pipeline mode (it’s not needed for Classic Pipeline mode)
So instead of the above you have this instead:
<system.webServer>
</modules>
<add name="..." type="..." />
</modules>
<handlers accessPolicy="Read, Write, Script, Execute">
<add verb="...." name="..." path="..." type="..." />
</handlers>
</system.webServer>
Notice there are a couple slight changes, which means you can;t just copy and paste
these as-is from <system.web> into <system.webServer>:
<httpModules> and <httpHandlers> have been renamed to <modules> and <handlers>, respectively.
Each handler in IIS7 requires a name attribute. If you don;t specify it, you'll get an error message.
The handlers node has an optional, but good-to-define accessPolicy attribute.
This value depends on your handlers, so use the ones that are right for you."
Second
There are some restrictions in IIS7 when you are running in Integrated mode.
For example you cannot do calls to the request property of an HttpContext object.
All calls to HttpContext.Current.Request will have a problem because Request will be null.
You can see more details here:
http://mvolo.com/blogs/serverside/archive/2007/11/10/Integrated-mode-Request-is-not-available-in-this-context-in-Application_5F00_Start.aspx