Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc Working with IHttpContextAccessor especially from ported library code without direct DI access #6113

Closed
Rick-Anderson opened this issue Apr 28, 2018 · 1 comment
Assignees
Labels
Pri1 High priority, do before Pri2 and Pri3

Comments

@Rick-Anderson
Copy link
Contributor

@mjrousos can you provide notes/draft on this?

@Rick-Anderson Rick-Anderson added the Pri1 High priority, do before Pri2 and Pri3 label Apr 28, 2018
@Rick-Anderson Rick-Anderson added this to To do in LS-follow-up via automation Apr 28, 2018
@mjrousos
Copy link
Member

mjrousos commented May 1, 2018

@coderandhiker is going to work on this one.

Essentially, it just boils down to adding an explanation of what IHttpContextAccessor does, why it's useful, and when it should be used (and when it shouldn't be :))

This StackOverflow post explains the challenge that ASP.NET developers may have coming to ASP.NET Core without an HttpContext.Current API and how IHttpContextAccessor can help. This GitHub issue explains that it's not in the DI container by default.

Here are some notes I took on this one previously during a code porting project:

System.Web.HttpContext is not used in ASP.NET Core. A new ASP.NET Core version of HttpContext is available (in the Microsoft.AspNetCore.Http namespace), but it doesn’t have a .Current static property. This is because ASP.NET Core does not depend on global statics, retrieving state by dependency injection instead.

To fix code that was using HttpContext.Current, one of the following approaches can be used:

  1. If the code using HttpContext.Current is in middleware or a controller, then the current HttpContext can be retrieved directly from the dependency injection container, instead.
  2. If the code using HttpContext.Current is called from a controller or middleware component, then the current context can be passed as a parameter.
  3. If neither of those works, a static helper can retrieve an IHttpContextAccessor from dependency injection and use that to query for the current HttpContext.

For new development, options 1 and 2 should usually work. In the case of some projects, though, there may be many uses of HttpContext.Current in existing code that would take a lot of changes to re-write to use option 2. To deal with this, we can use option 1 where possible and then add IHttpContextAccessor to the dependency injection container (using AddHttpContextAccessor since it is not there by default) and create a helper class that the Startup.Configure method populates with an instance of IHttpContextAccessor. Code without direct access to the DI container can call a static method on that class to get the IHttpContextAccessor.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Pri1 High priority, do before Pri2 and Pri3
Projects
No open projects
LS-follow-up
  
Done
Development

No branches or pull requests

2 participants