Getting your context

You will probably remember the HttpContext class from ASP.NET. The current instance of this class would represent the current context of execution, which included both the request information and the response channel. It was ubiquitous, and even though in Web Forms it was sometimes hidden, it was the way by which the web application communicated with the client.

Of course, ASP.NET Core also has an HttpContext class, but there is a big difference: there is no longer a Current static property that lets us get hold of the current context—instead, the process is a bit more convoluted. Anyway, all of the infrastructure classes—middleware, controllers, views, Razor pages, view components, tag helpers, and filters—allow easy access to the current context. Those who don't can leverage the IHttpContextAccessor interface through DI and get a pointer to the current context:

//this is required to register the IHttpContextAccessor
//services.AddHttpContextAccessor();

...

public MyType(IHttpContextAccessor httpContextAccessor)
{
    var httpContext = httpContextAccessor.HttpContext;
}

So, besides User, Request, and Response properties, which are mostly similar to their pre-Core counterparts, we also have the following:

• A Features collection, which exposes all of the features implemented by the current hosting server (Kestrel, WebListener/HTTP.sys, and more).
• A RequestServices property, which gives us access to the built-in DI framework (more on this in the following chapters).
• A TraceIdentifier property, which uniquely identifies a request in ASP.NET Core 2.x; in earlier versions, we had to access this through a feature.

• A Connection object, from which we can obtain relevant information about the client connection, such as the client certificates, for example:
  • The Authentication object, giving easy access to security primitives, such as sign in, sign out, deny, and more.
  • The Session object, which is implemented by the ISessionFeature feature, and is exposed directly by the HttpContext.
  • The ClientCertificate property contains any SSL certificate sent by the client as part of the handshake protocol.

The context is a vital part of an ASP.NET Core application, as we will see.

Working with the context

The main operations we will likely be doing with the context are as follows:

• Reading values from the request
• Writing to the response
• Reading and writing cookies
• Getting the current user
• Getting the address of the remote user
• Accessing the session
• Accessing services from the DI framework

Here are some examples:

//writing to the response
HttpContext.Response.StatusCode = 200;
HttpContext.Response.ContentType = "text/plain";
HttpContext.Response.WriteAsync("Hello, World!");

//getting values from the request
var id = HttpContext.Request.Query["id"].Single();
var host = HttpContext.Request.Host;
var payload = HttpContext.Request.Form["payload"].SingleOrDefault();

//reading and writing cookies
var isAuthenticated = HttpContext.Request.Cookies["id"].Any();
HttpContext.Response.Cookies.Append("id", email);

//getting the current user
var user = HttpContext.User;

//getting the address of the remote user
var ip = HttpContext.Connection.RemoteIpAddress;

//accessing the session
HttpContext.Session.SetString("id", email);
var id = HttpContext.Session.GetString("id");

//getting services from DI
var myService = HttpContext.RequestServices.Get<IMyService>();

Essentially, everything we will be doing through constructs, such as MVC's controllers and actions, are built around these and other simple HttpContext operations. The next topic we will look at is the OWIN pipeline.