Migrates ASP.NET Framework HttpContext, Request, and Response usage to ASP.NET Core equivalents. Use when projects reference HttpContext.Current, HttpRequest.InputStream, HttpResponse.Write, HttpServerUtility, Request.ServerVariables, Request.Files, Response.End, Response.AddHeader, or ClaimsPrincipal.Current. Also triggers for "replace HttpContext.Current", "inject IHttpContextAccessor", "async response writing", "request body reading", or when assessment signals include UsesHttpContextCurrent, UsesHttpContext, UsesResponseWrite, UsesRequestInputStream, UsesCustomHeaders.
Migrates ASP.NET Framework HttpContext, Request, and Response usage to ASP.NET Core equivalents. Use when projects reference HttpContext.Current, HttpRequest.InputStream, HttpResponse.Write, HttpServerUtility, Request.ServerVariables, Request.Files, Response.End, Response.AddHeader, or ClaimsPrincipal.Current. Also triggers for "replace HttpContext.Current", "inject IHttpContextAccessor", "async response writing", "request body reading", or when assessment signals include UsesHttpContextCurrent, UsesHttpContext, UsesResponseWrite, UsesRequestInputStream, UsesCustomHeaders.
ASP.NET MVC HttpContext and Request/Response Migration
Overview
Migrate HttpContext.Current, HttpRequest, HttpResponse, and HttpServerUtility usage from ASP.NET Framework to ASP.NET Core. The static HttpContext.Current accessor is removed in Core — all context access flows through dependency injection or controller base class properties. Response writing is async-only in Kestrel, and request reading APIs have changed types and behavior.
Adapter precedence: If the migrating-mvc-system-web-adapters skill is loaded, its guidance takes precedence over HttpContext.Current, Request Access, Response Access, and ClaimsPrincipal.Current sections during scaffold and migrate task phases.
Threading concern: IHttpContextAccessor uses AsyncLocal<T>. In singleton services, always access .HttpContext at call time — never cache the HttpContext reference in a field. A cached reference may belong to a completed request and produce null-reference or cross-request data leaks.
In static helpers or libraries with no DI — this requires an architectural change. Pass HttpContext (or the specific value needed) as a method parameter from the call site. Avoid wrapping IHttpContextAccessor in a static accessor because it reintroduces the same coupling.
Step 3: Migrate Request Access Patterns
Request APIs changed types and behavior between Framework and Core:
Headers must be set before writing to the response body. In Framework this was loosely enforced; in Core, writing headers after the response has started throws an InvalidOperationException.
Response.Redirect() — compatible but behavior differs:
Response.Redirect("/home"); // Sets 302, does NOT abortreturn; // Must explicitly return
Core's Redirect does not end the response or call Response.End(). Always return from the action or middleware after calling Redirect() to prevent further processing.
Response buffering — Core does not buffer responses by default. For scenarios requiring buffering (e.g., setting headers after partial writes), use Response.StartAsync() awareness or enable response buffering middleware.
Step 5: Replace HttpServerUtility Calls
HttpContext.Current.Server (HttpServerUtility) has no single replacement in Core. Replace method by method:
Server. Method
ASP.NET Core Replacement
Server.MapPath("~/path")
IWebHostEnvironment.ContentRootPath or .WebRootPath + Path.Combine()
Server.HtmlEncode(s)
System.Net.WebUtility.HtmlEncode(s) or HtmlEncoder.Default.Encode(s)
Server.HtmlDecode(s)
System.Net.WebUtility.HtmlDecode(s)
Server.UrlEncode(s)
System.Net.WebUtility.UrlEncode(s) or Uri.EscapeDataString(s)
Server.UrlDecode(s)
System.Net.WebUtility.UrlDecode(s) or Uri.UnescapeDataString(s)
Server.Transfer(url)
No equivalent — rewrite as redirect or internal rewrite middleware
Server.Execute(url)
No equivalent — refactor to call the target logic directly
Server.GetLastError()
IExceptionHandlerFeature in exception handler middleware
Server.ScriptTimeout
RequestTimeoutOptions or CancellationToken with timeout
Custom ClaimsPrincipal factories that set ClaimsPrincipal.Current should be replaced with claims transformation. Register an IClaimsTransformation implementation:
Remove using System.Web statements that are no longer needed
Remove any custom HttpContextBase / HttpContextWrapper abstractions
Remove HttpContext.Current shim or facade classes
Search for remaining references to HttpContext.Current, ClaimsPrincipal.Current, HttpServerUtility, Request.ServerVariables, Response.Write( (sync overload), and Response.End()
Success Criteria
No references to HttpContext.Current remain in the project
IHttpContextAccessor registered and injected where services need HttpContext
No singleton services cache HttpContext references in fields
All Request.InputStream reads converted to async Request.Body reads
All Response.Write() calls converted to await Response.WriteAsync() or IActionResult
Response.End() calls removed and replaced with return statements or HttpContext.Abort()
HttpServerUtility calls replaced with Core equivalents
ClaimsPrincipal.Current replaced with User property or IHttpContextAccessor
