-
Notifications
You must be signed in to change notification settings - Fork 447
Null HttpContext with long polling #1644
Comments
Yeah, this is a tricky one because the connection is long-living but the HttpContext is only associated with a single Send, Poll, EventSource stream or WebSocket request. Perhaps we need to just remove the HttpContext entirely and copy any relevant data into the ConnectionContext. |
Since we are decoupled from the actual hub invocation process we're going to remove the HttpContext from the connection features. Instead, we're going to need to copy data from the HttpContext (Headers and QueryString). |
Also Connection info (IP Addresses, ports) |
@anurse I had an evil idea. Still set an HttpContext but with the copied data. The benefit is that it just works with all of the APIs that take an http context (like the auth methods) but it's harmless since it isn't valid as write to or read from (the bodies), and it has the properties that people want. |
It's not that crazy. We'd need to poison, or |
Yep, I'm going to do this. |
A hub method that accesses the
HttpContext
can get null instead if the method was invoked while the poll request ended.SignalR/src/Microsoft.AspNetCore.Sockets.Http/HttpConnectionDispatcher.cs
Line 279 in 0e38ee3
This has shown up with
HubConnectionTests.ClientCanSendHeaders(transportType: LongPolling)
on OSX build.https://travis-ci.org/aspnet/SignalR/jobs/355210173#L1309
The text was updated successfully, but these errors were encountered: