Blazor SSR APIs for accessing HttpContext without IHttpContextAccessor
See original GitHub issueIdeally we’d support things like:
[FromHttpContext] public HttpRequest Request { get; set; }
[FromHttpContext] public HttpResponse Response { get; set; }
This is useful for things like:
- Reading the HTTP method
- Reading and writing cookies
- Setting arbitrary response headers
Issue Analytics
- State:
- Created 3 months ago
- Reactions:5
- Comments:12 (12 by maintainers)
Top Results From Across the Web
How do I access HttpContext in Server-side Blazor?
Thus the only place from which you can access the HttpContext, without even adding the IHttpContextAccessor to the DI container, ...
Read more >Access HttpContext in ASP.NET Core
Blazor apps run outside of the ASP.NET Core pipeline context. The HttpContext isn't guaranteed to be available within the IHttpContextAccessor, ...
Read more >How do you use the HttpContext object in Blazor server- ...
Use HttpContext through the IHttpContextAccessor interface to get the user agent details in a Blazor Server application. The following example demonstrates ...
Read more >Accessing the ASP.NET Core Base URL: So Many Ways
My Specific Situation: Accessing my App's base URL for API calls. If you haven't heard, I've been building a Blazor server app for...
Read more >Stefan Đokić's Post - dotnet #softwareengineer #csharp
IHttpContextAccessor is an abstraction over the HttpContext object that allows it to be ... NET Core | Web API | Blazor | SQL...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I guess it uses the AsyncLocal trick because it’s registered as a singleton. TBH I don’t know why
IHttpContextAccessor
is registered as singleton and not scoped, but perhaps it’s for back compat reasons. We wouldn’t need to do the same here.If anyone knows of reasons why we shouldn’t have
HttpContext
accessible through a scoped service, please say so!I think consistency wins here so sticking with the longer form name until such time we decide to support terser names for all the parameter-source attributes.