Access HttpContext from HttpResource: 3 Key Ways for 2025

[ApiController]
[Route("api/[controller]")]
public class InfoController : ControllerBase
{
    [HttpGet("user-agent")]
    public IActionResult GetUserAgent()
    {
        // The HttpContext is a property on ControllerBase
        var userAgent = HttpContext.Request.Headers["User-Agent"].ToString();

        if (string.IsNullOrEmpty(userAgent))
        {
            return NotFound("User-Agent header not found.");
        }

        return Ok(new { UserAgent = userAgent });
    }
}

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/ip", (HttpContext context) => 
{
    var remoteIp = context.Connection.RemoteIpAddress?.ToString();
    return Results.Ok(new { IpAddress = remoteIp ?? "Not available" });
});

app.Run();

This is where IHttpContextAccessor comes in. It’s a service that provides access to the current request's HttpContext from anywhere in your application where dependency injection is available.

Step 1: Register the Service

First, you need to register IHttpContextAccessor with the DI container in your Program.cs file. It's a simple one-liner.

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddControllers();

// This is the magic line!
builder.Services.AddHttpContextAccessor();

// ... register other services

var app = builder.Build();
// ...
app.Run();

Note: Many ASP.NET Core project templates, especially those using Identity, already include this for you. But it's good to know where it comes from!

Step 2: Inject and Use It

Now you can inject IHttpContextAccessor into any of your services and use it to access the current HttpContext.

public interface IAuditService
{
    string GetCurrentRequestId();
}

public class AuditService : IAuditService
{
    private readonly IHttpContextAccessor _httpContextAccessor;

    // Inject the accessor via the constructor
    public AuditService(IHttpContextAccessor httpContextAccessor)
    {
        _httpContextAccessor = httpContextAccessor;
    }

    public string GetCurrentRequestId()
    {
        // IMPORTANT: The HttpContext property can be null!
        // Always use the null-conditional operator (?.) for safety.
        return _httpContextAccessor.HttpContext?.TraceIdentifier ?? "No-Context";
    }
}

A Critical Caveat

There's one huge rule when using IHttpContextAccessor: the HttpContext property can be null.

This happens when your code is executed outside the context of an HTTP request. For example:

• In a background worker service (e.g., an IHostedService).
• During application startup in Program.cs.
• In a unit test where the HTTP pipeline isn't simulated.

Always, always use the null-conditional operator (?.) when accessing _httpContextAccessor.HttpContext to avoid a nasty NullReferenceException that can bring down your application.

While incredibly useful, think of IHttpContextAccessor as a tool of last resort. If you can use direct injection, prefer it. Overusing the accessor can make your code harder to reason about and test, as it creates an "ambient" dependency on the HTTP context.

3. Middleware & Filters: The Cross-Cutting Approach

Sometimes you need to inspect or modify the HttpContext for a whole group of requests, not just within a single endpoint. This is where cross-cutting concerns like logging, authentication, caching headers, or exception handling come into play. For these scenarios, middleware and filters are your best friends.

Using Custom Middleware

Middleware components form the request processing pipeline in ASP.NET Core. Each piece of middleware has direct access to the HttpContext and can perform actions before or after the next component in the pipeline is called. This is perfect for logic that should run on every single request.

Here’s a simple middleware that logs the request path and the eventual response status code:

public class RequestTimingMiddleware
{
    private readonly RequestDelegate _next;
    private readonly ILogger<RequestTimingMiddleware> _logger;

    public RequestTimingMiddleware(RequestDelegate next, ILogger<RequestTimingMiddleware> logger)
    {
        _next = next;
        _logger = logger;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        var stopwatch = System.Diagnostics.Stopwatch.StartNew();
        
        // Let the rest of the pipeline run
        await _next(context);
        
        stopwatch.Stop();
        _logger.LogInformation(
            "Request {path} finished in {elapsedMs}ms with status {statusCode}",
            context.Request.Path,
            stopwatch.ElapsedMilliseconds,
            context.Response.StatusCode);
    }
}

// To use it, add this in Program.cs:
// app.UseMiddleware<RequestTimingMiddleware>();

The HttpContext is passed directly to the InvokeAsync method, giving you full control over the request and response at a specific point in the pipeline.

Using Action Filters

Filters are similar to middleware but operate within the MVC/API Controller framework. They give you hooks into specific stages of request processing, like right before an action method is executed (OnActionExecuting) or just after (OnActionExecuted). This is ideal when you need context-aware logic that only applies to controller actions.

For example, an action filter could be used to validate a model or add a custom response header:

public class AddCorrelationIdHeaderFilter : IActionFilter
{
    public void OnActionExecuting(ActionExecutingContext context)
    {
        // Runs before the action method. 
        // context.HttpContext is readily available.
        var correlationId = context.HttpContext.TraceIdentifier;
        context.HttpContext.Response.Headers.Append("X-Correlation-ID", correlationId);
    }

    public void OnActionExecuted(ActionExecutedContext context)
    {
        // Runs after the action method, before the result is executed.
    }
}

// You can then apply this filter globally, to a controller, or to a specific action:
// [ServiceFilter(typeof(AddCorrelationIdHeaderFilter))]

Filters provide a powerful way to encapsulate logic that depends on HttpContext without cluttering your action methods.

Tying It All Together: Which Method to Choose?

Navigating HttpContext access in 2025 is all about choosing the right pattern for the context. Here’s a quick cheat sheet:

• When you're in a Controller or Minimal API:
  Use Direct Injection. Access the HttpContext property on ControllerBase or add it as a parameter to your minimal API handler. It's the cleanest, most performant, and most testable approach.
• When you're in a downstream service (e.g., business logic, data access):
  Use the IHttpContextAccessor. It decouples your services from the web layer. Just remember to handle the potential for a null context and use it judiciously.
• When you need to handle cross-cutting concerns (logging, auth, headers):
  Use Middleware or Filters. Middleware is great for pipeline-level logic affecting all requests, while filters are perfect for targeted, action-specific enhancements in your controllers.

By understanding these three fundamental techniques, you can write cleaner, more maintainable, and more robust ASP.NET Core APIs. Happy coding!