In SSR, supply HttpContext as cascading value

[SteveSandersonMS]

Fixes #48769

Usage

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

In SSR, this will receive the HttpContext. In other rendering modes where there is no HTTP context, no value will be supplied so the property will remain null.

Alternative design considered

In #48769 I suggested using [SupplyParameterFromHttpContext] but that turns out not to be practical unless we either (a) make ICascadingValueSupplier public, or (b) add an IVT from M.A.Components to .Endpoints.

I'm not keen on doing either of the above on a whim. Plus, use of [CascadingValue] has advantages:

• It's consistent with the existing pattern for authentication state (we have [CascadingParameter] Task<AuthenticationState> AuthenticationStateTask { get; set; }).
• Longer term, if we add more things like this, it would be nice not to add a separate special attribute for each one when [CascadingParameter] is already descriptive enough. Special attributes are needed only when the type of thing being supplied might reasonably clash with something else the application is doing (for example, we do need it for form/query, as they supply arbitrary types).

Review notes

It's best to look at the two commits in this PR completely separately:

1. The first commit fixes an API design problem I discovered while considering how to do this. I realised that when we added CascadingParameterAttributeBase, we made a design mistake:
   • We put the Name property on the abstract base class just because CascadingParameterAttribute, SupplyParameterFromQuery, and SupplyParameterFromForm all have a Name.
   • However, in all three cases there, the Name has completely different meanings. For CascadingParameterAttribute, it's the name associated with <CascadingValue Name=...>, whereas for form it's the Request.Form entry or fall back on property name, and for query it's the Request.Query entry or fall back on property name. In general there's no reason why a CascadingParameterAttributeBase subclass should have a Name at all (SupplyParameterFromHttpContext wasn't going to), and if it does have one, its semantics are specific to it. So these should not be the same properties.
   • The change we made to make CascadingParameterAttribute.Name virtual might even be breaking (see https://learn.microsoft.com/en-us/dotnet/core/compatibility/library-change-rules stating DISALLOWED: Adding the virtual keyword to a member). So it's good we can revert that here.
2. The second commit is the completely trivial implementation of supplying HttpContext as a cascading value, with an E2E test.

[SteveSandersonMS]

@javiercn Thanks for reviewing.

This is worth a quick re-review (at least of the new final commit) because the tests failed in a way that showed we had a missing scenario and I think need some new public API. The "add cascading parameter at root" API only had an Add flavour and not a TryAdd, but our DI setup logic would always want to use TryAdd for this. Application and library developers will also have reasons to want the TryAdd version of DI registration too. So I've added this here. Any concerns?

[javiercn]

Do we always register an EndpointHtmlRenderer? Should this be sp.GetService?.HttpContext`?

[SteveSandersonMS]

If we're running this code, we do always register it - that's on line 53 above.

[SteveSandersonMS]

@mkArtak Another one to merge for release/8.0. Again this changes PublicAPI.Unshipped.txt so the code check failure is expected and should be merged regardless.

[davidfowl]

Very nice making this a cascading value

[iphdav]

@SteveSandersonMS @MackinnonBuck I like what has been implemented here. However I just want to give the feedback that it will seem strange to most end developers using blazor server (Interactive Server), that they can inject IHttpContextAccessor into a component, and yet get NULL if they have a cascading parameter of type HttpContext.

We all completely understand that at this point in the lifecycle we are on a web socket connection (and cannot for example change the response or set a http header). But lots of "Interactive Server" components still check for maybe the User (on the HttpContext) or check the URL they are on (rather than using NavigationManager); or check a cookie, etc. All read-only stuff, which should be fine.

I am just pointing out the inconsistency with "Interactive Server" of allowing IHttpContextAccessor; yet getting NULL for the Cascading Parameter implementation you have done. It just seems yet another thing that would need explaining to new developers. Why not align it with the behaviour of IHttpContextAccessor for developers that prefer to use "Interactive Server" mode?

[ghost]

Hi @iphdav. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context.

[Sasino97]

@SteveSandersonMS @MackinnonBuck I like what has been implemented here. However I just want to give the feedback that it will seem strange to most end developers using blazor server (Interactive Server), that they can inject IHttpContextAccessor into a component, and yet get NULL if they have a cascading parameter of type HttpContext.

We all completely understand that at this point in the lifecycle we are on a web socket connection (and cannot for example change the response or set a http header). But lots of "Interactive Server" components still check for maybe the User (on the HttpContext) or check the URL they are on (rather than using NavigationManager); or check a cookie, etc. All read-only stuff, which should be fine.

I am just pointing out the inconsistency with "Interactive Server" of allowing IHttpContextAccessor; yet getting NULL for the Cascading Parameter implementation you have done. It just seems yet another thing that would need explaining to new developers. Why not align it with the behaviour of IHttpContextAccessor for developers that prefer to use "Interactive Server" mode?

I agree, as a new Blazor dev I'm completely confused. I understand that there's no HTTP context once the initial connection has been made, but why isn't there a straightforward way to get the state of that initial connection, so that for example I can get the request headers, the IP address, and other important values.

[ghost]

Hi @Sasino97. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context.