Description
Provide a doc section on the SignalR docs that provides guidance on the usage of HttpContext and that discourages using IHttpContextAccessor within SignalR.
Indicate that the HttpContext instance might not even exist and that it is dependent on the transport. (For example, websockets gets a single context that is the result of the initial handshake, long polling gets a new context per client "poll" request and signalr service gets a "mocked/faked/shim context")
Explain that accessing the context through IHttpContext accessor is a bad practice as in most cases it will simply be null.
Metadata
Metadata
Assignees
Type
Projects
Status
Done
Activity
javiercn commentedon Oct 10, 2019
We get a bunch of issues like this:
dotnet/aspnetcore#14878
We should have a doc we can point people to.
Rick-Anderson commentedon Oct 11, 2019
@BrennanConroy @bradygaster if you can get this drafted we'll help get it published. Should it go in an include so you can include it in multiple docs?
analogrelay commentedon Oct 11, 2019
I think a full doc make sense. Something like "Using HttpContext in SignalR and Blazor Server-Side apps". Perhaps we can have an include that we can put in a few places to put a note call-out something like "Using HttpContext in SignalR or Blazor Server-Side apps has some caveats, see [doc] for details".
We can look at pulling a draft together to start this process. It's definitely something that's affected SignalR users (not just Blazor users).
Rick-Anderson commentedon Nov 6, 2019
@BrennanConroy @bradygaster if you can get this drafted we'll get it published. Should it go in an include so you can include it in multiple docs?
31 remaining items