It contains the Request, Response, Context and Server classes. These give you access to useful methods. Here we find the best, fastest way to access these objects.
Intro. I was puzzled because many books and sites will use both "HttpContext.Current.Request" and Request. I thought a quick investigation into the difference here would be interesting. Let us first look at MSDN.
Because the HttpContext.Request property is of type HttpRequest, the ASP.NET intrinsic Request object has all the properties and methods of HttpRequest automatically available to it. Thus to get the length, in bytes, of the content sent by the client browser, you only need to specify the Request.ContentLength.
In this quotation, we see the word intrinsic. This refers to just directly using Request. The two constructs are HttpContext.Current.Request.ContentLength and Request.ContentLength.
Info: The difference is that HttpContext.Current.Request is accessed through a static property.
And: Request is accessed directly from the base class HttpApplication. Using HttpContext.Current.Request introduces overhead to your call.
Code. In investigating this, I disassembled some example code with IL Disassembler. For my example, I access the Request.PhysicalPath. Both lines of code are independent. After the code, we will look at its compiled version.
Example code: C# // // 1. // string physical = Request.PhysicalPath; // // 2. // string physical2 = HttpContext.Current.Request.PhysicalPath;
How it compiles. Next we see what those two string assignments become in the intermediate language—this is what C# is compiled into. The first part is for line 1, and the second is for line 2.
Intermediate language instructions 1 IL_0023: call instance class [System.Web]System.Web.HttpRequest [System.Web]System.Web.HttpApplication::get_Request() IL_0028: callvirt instance string [System.Web]System.Web.HttpRequest:: get_PhysicalPath() Intermediate language instructions 2 IL_002e: call class [System.Web]System.Web.HttpContext [System.Web]System.Web.HttpContext::get_Current() IL_0033: callvirt instance class [System.Web]System.Web.HttpRequest [System.Web]System.Web.HttpContext::get_Request() IL_0038: callvirt instance string [System.Web]System.Web.HttpRequest:: get_PhysicalPath()
What's important to know? The two ways of accessing the Request members are identical, except when you use "HttpContext.Current" you incur another property overhead. The page, or global.asax, has the base type of HttpApplication.
So: It is best to just directly access Request, Server, Context or Response objects.
Example. After my investigation, I changed some parts of my code to use the more concise code. Here are some things I fixed. In each of these cases I eliminated one property access. This changes the compiled code.
In our programs, we should directly use the HttpApplication and avoid calling HttpContext at all. It results in smaller IL and probably is faster. Simpler is better and usually much faster.
Before and after example code: C# // // A. // Before optimization // Response.Write(HttpContext.Current.Server.HtmlEncode(terms)); // // A. // After optimization // Response.Write(Server.HtmlEncode(terms)); // // B. // Before optimization // HttpContext.Current.RewritePath("~/default.aspx?file=" + key, false); // // B. // After optimization // Context.RewritePath("~/default.aspx?file=" + key, false);
Summary. Here we saw that you can use the "intrinsic" Request, Response, Server, and Context objects. This results in shorter code and is more efficient. Using these objects is so common that doing it optimally is important.
Also: We used the IL Disassembler tool to gain insight into how ASP.NET internally works.