Blazor SSR APIs for accessing HttpContext without IHttpContextAccessor

[SteveSandersonMS]

Ideally 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

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[DamianEdwards]

Some concrete examples where I hit needing this when porting an app from Razor Pages to Blazor SSR:

• Setting HTTP response caching headers
• Getting HttpContext.TraceIdentifier for the app's Error.razor page

[danroth27]

@mkArtakMSFT I think we're going to need this one for .NET 8. We should discuss adding this to rc1.

[SteveSandersonMS]

@danroth27 The rationale we give for not using IHttpContextAccessor in Blazor doesn't apply in SSR. Is the reason for wanting an alternative way to reach HttpContext purely to keep the guidance easy to understand, or is there some other objective problem we're trying to avoid?

Anything we implement to reach HttpContext is internally going to be exactly equivalent to IHttpContextAccessor. If you're aware of some subtleties I'm missing please let me know. Update: no, not equivalent - see below.

[danroth27]

The rationale we give for not using IHttpContextAccessor in Blazor doesn't apply in SSR

What about the rationale we give for not using IHttpContextAccess in general?:

This interface should be used with caution. It relies on AsyncLocal which can have a negative performance impact on async calls. It also creates a dependency on "ambient state" which can make testing more difficult.

@davidfowl @DamianEdwards

[SteveSandersonMS]

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!

[halter73]

TBH I don't know why IHttpContextAccessor is registered as singleton and not scoped, but perhaps it's for back compat reasons.

I remember this conversation back when we added IHttpContextAccessor. IIRC, the primary example given was a singleton logging provider that enriched logs with details from the HttpContext.

[SteveSandersonMS]

@davidfowl @DamianEdwards Pinging the two of you as we just about have time for taking one last action here.

There will definitely be cases where people want to access Request/Response in Blazor SSR, e.g., for reading/writing headers/etc. As of right now people would have to use IHttpContextAccessor, which we don't love because even though it would be technically safe in the Blazor SSR case, people may later add @rendermode Server and make it unsafe, or they might just get into the habit of using it everywhere and there is a claim that it could adversely affect perf.

If it's true that we really should be pushing people away from IHttpContextAccessor, then our best option would be something like:

• In Blazor SSR, support parameters like the following (probably supporting just these three):
  • [SupplyParameterFromHttpContext] public HttpContext? Context { get; set; }
  • [SupplyParameterFromHttpContext] public HttpRequest? Req { get; set; }
  • [SupplyParameterFromHttpContext] public HttpResponse? Resp { get; set; }
• In other Blazor hosting models (e.g., interactive Server/WebAssembly rendering, or MAUI), no values would be supplied for those parameters and hence they would be left as null. Developers will have to avoid reliance on those parameters in non-SSR cases.

I think we could still justify doing that if the desire to avoid IHttpContextAccessor is strong enough. However if we believe IHttpContextAccessor is acceptable to use in edge cases then perhaps this is unnecessary.

[DamianEdwards]

In Razor Pages/Views we have a pattern for properties whose values must be supplied by the framework but aren't values available from DI or provided by a base class. We call these "activated" values and have specific attributes for each value provided, e.g.

[ViewContext]
public ViewContext? ViewContext { get; set; }

They're conceptually similar to the way parameter values are declared in Blazor components, and thus inline with what you propose with the [SupplyParameterFromHttpContext] attribute. While it's a bit more verbose, it's consistent with the existing approach in Blazor today. I'm just not sure about the ability to supply the whole object, or values of properties, via the same attribute. I'd just stick to a way to get the whole HttpContext. Also, ideally, that attribute would be defined in an assembly only referenced by ASP.NET Core

An alternative approach would be to special-case @inject HttpContext Context in the Blazor host and have that set directly via the framework rather than injected. Drawback of that of course is in non-SSR scenarios it would try to inject it from DI and fail.

[danroth27]

I'd just stick to a way to get the whole HttpContext

👍