ASP.NET HttpContext Request

You have an ASP.NET website and want to use the Request, Response, Context, or Server classes, which give you access to useful methods. Here we find the best, fastest way to access these objects.

This ASP.NET article explores the Request property on HttpContext. It uses C# code.

Problem

I was puzzled because many books and sites will use "HttpContext.Current.Request" and Request interchangeably. I thought a quick investigation into the difference here would be interesting. Let's look at MSDN first.

What MSDN says: "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."

What that means: Microsoft uses the word intrinsic here, which refers to just using "Request" directly. The two constructs are "HttpContext.Current.Request.ContentLength" and "Request.ContentLength."

What's the difference? 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 simply introduces overhead to your call.

In investigating this, I disassembled some example code with ID Disassembler. For my example, I access the Request.PhysicalPath. Both of the lines of code are independent.

Example code [C#]

//
// 1.
//
string physical = Request.PhysicalPath;
//
// 2.
//
string physical2 = HttpContext.Current.Request.PhysicalPath;

How it compiles. What we see here next is what those two string assignments become in the intermediate language, which 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, just access Request, Server, Context, or Response directly.

Fix some examples

After my investigation, I changed some parts of my code to use the more concise code. Here are some things I fixed, and in each of these cases I eliminated one property access.

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);

Description. What we saw is that it is best to use the HttpApplication directly and to avoid calling HttpContext at all. It results in smaller IL and probably is faster. Simpler is better and usually much faster.

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. Use IL Disassembler to gain insight into how ASP.NET works internally.