[Blazor] HttpTransportType.LongPolling vs IHttpContextAccessor

[cubed-it]

Describe the bug

I have a simple component like this:

@using Microsoft.AspNetCore.Http
@inject IHttpContextAccessor ContextAccessor

@if (!_isBearerContext)
{
    @ChildContent
}

@code {
    [Parameter]
    public RenderFragment ChildContent { get; set; }

    bool _isBearerContext = false;

    protected override void OnInitialized()
    {
        _isBearerContext = ContextAccessor.HttpContext.Request.Headers.Any(x => x.Key == "Authorization");

        base.OnInitialized();
    }

}

and now I force

endpoints.MapBlazorHub(options =>
            {
               options.Transports = HttpTransportType.LongPolling;
            });

Then the result is a NullReferenceException for ContextAccessor.HttpContext.

First of all, is this behavior meant to be?

If so, then: How can I access the copied values? aspnet/SignalR#1684 #14167

Or: What would be an alternative approach to access headers in subsequent long polling requests?
How can I uniquely match a long polling request to the first request, if e.g. I would cache the headers myself?

Thanks!

[javiercn]

@cubed-it thanks for contacting us.

This is more of a signalr question than a Blazor question, so I can't really go into the details. What I can tell you is that we actively discourage you from using IHttpContextAccessor in your server-side Blazor applications since it is not reliable.

Depending on what you are trying to do, we recommend passing all the data you need from the request/context during app bootstrapping process as parameters to the root component that gets rendered in _Host.cshtml

[cubed-it]

@javiercn thanks for the quick help. I think this should work. I also just found another answer from you on pretty much the same subject ;)
#18183

Maybe the documentation should be extended in this aspect? At least I can't remember seeing a dont use IHttpContextAccessor warning anywhere. :/