HttpContext is valid in Interactive Server Rendering Blazor page

[huazhb]

Description

On the website, it says "IHttpContextAccessor must be avoided with interactive rendering because there isn't a valid HttpContext available." which seems not true. I use the IHttpContextAccessor on the Blazor page using Interactive Server rendering and I can access the HttpContext from IHttpContextAccessor without any issue. When switch to Interactive Client it will be null. (Of course it is since it is running on client side). So, I don't know where this statement coming from, or it will be invalid under some circumstances? Can anyone double check if this statement is valid for all Interactive rendering mode or it is only valid for the Interactive client mode?

Thank you

Page URL

https://learn.microsoft.com/en-us/aspnet/core/fundamentals/http-context?view=aspnetcore-8.0

Content source URL

https://github.com/dotnet/AspNetCore.Docs/blob/main/aspnetcore/fundamentals/http-context.md

Document ID

79cb05f8-9ac0-26a8-8434-15de071160c3

Article author

@guardrex

Related Issues

[guardrex]

Hello @huazhb ... Yes, this is a point of confusion. This section is placed here via an INCLUDE file that also appears in the SignalR article and in the Threat Mitigation article. The section's guidance is the latest that I received from the product unit on the subject. Let's double-check this now and clear this up.

@MackinnonBuck ... This is one of the questions on my list of items to address, so we may as well tackle it now.

Here's the section (via the INCLUDE) ...

<xref:Microsoft.AspNetCore.Http.IHttpContextAccessor> must be avoided with interactive rendering because there isn't a valid `HttpContext` available.

<xref:Microsoft.AspNetCore.Http.IHttpContextAccessor> can be used for components that are statically rendered on the server. **However, we recommend avoiding it if possible.**

<xref:Microsoft.AspNetCore.Http.HttpContext> can be used as a cascading parameter only in *statically-rendered root components* for general tasks, such as inspecting and modifying headers or other properties in the `App` component (`Components/App.razor`). The value is always `null` for interactive rendering.

[CascadingParameter]
public HttpContext? HttpContext { get; set; }

For scenarios where the <xref:Microsoft.AspNetCore.Http.HttpContext> is required in interactive components, we recommend flowing the data via persistent component state from the server. For more information, see <xref:blazor/security/additional-scenarios#pass-tokens-to-a-server-side-blazor-app>.

Cross-reference (LIVE section example): https://learn.microsoft.com/en-us/aspnet/core/fundamentals/http-context?view=aspnetcore-8.0#ihttpcontextaccessorhttpcontext-in-razor-components-blazor

That came about from my chat with either (or both) you and Javier.

There's a related issue on the samples repo about this that boils down to code in the BWA+OIDC sample app ...

https://github.com/dotnet/blazor-samples/blob/main/8.0/BlazorWebAppOidcBff/BlazorWebAppOidc/ServerWeatherForecaster.cs

... where the ServerWeatherForecaster is using IHttpContextAccessor to check for an HttpContext. Can you go through the rendering process step-by-step and explain if that code is running interactively or not ... and if it is running interactively (e.g., after prerendering on the server) then how it isn't in conflict with the general guidance on use of IHttpContextAccessor, both the 'don't do it' part and the 'it's always null for interactive rendering' part?

[guardrex]

From Mackinnon offline ...

The IHttpContextAccessor question is something I'm not sure about either. The app gets rendered using the InteractiveAuto render mode, and it seems like things would break if that resolved to using server interactivity. I think Stephen would be the one to ask about that.

Ping to @halter73 to take a look at this issue and recommend updates for the section on IHttpContextAccessor/HttpContext. It looks like we're missing caveats (or it's just plain wrong) ...

• For IHttpContextAccessor, we state that it's ok to use it "for components that are statically rendered on the server."
• For HttpContext, we state that it "can be used as a cascading parameter only in statically-rendered root components for general tasks, such as inspecting and modifying headers or other properties in the App component."

Should these remarks include a caveat for client request processing by the server project, including server-side services used by that processing, or is the current guidance just plain wrong?