Allow SocketsHttpHandler.ConnectCallback for sync requests #45300
Conversation
HTTP/1.1 support with sync requests currently doesn't work when a ConnectCallback is specified, even though a developer who wanted to make synchronous requests could provide a synchronously-completing callback. This also consolidates the connect logic across sync/async, avoids an extra delegate, etc.
|
Tagging subscribers to this area: @dotnet/ncl Issue DetailsHTTP/1.1 support with sync requests currently doesn't work when a ConnectCallback is specified, even though a developer who wanted to make synchronous requests could provide a synchronously-completing callback. This also consolidates the connect logic across sync/async, avoids an extra delegate, etc. Contributes to #44876
|
| // we could add a Boolean to SocketsHttpConnectionContext (https://github.com/dotnet/runtime/issues/44876) to let the callback know whether | ||
| // this request is sync or async. For now, log it and block. | ||
| Trace($"{nameof(SocketsHttpHandler.ConnectCallback)} completing asynchronously for a synchronous request."); | ||
| stream = streamTask.AsTask().GetAwaiter().GetResult(); |
There was a problem hiding this comment.
Shouldn't we rather throw instead of blocking for sync?
There was a problem hiding this comment.
That was what I did initially, but I think that's problematic because it's non-deterministic: if the operation happens to complete by the time we check, it won't throw, but if it doesn't, it will. That then makes it much more likely you'll only experience the failures once you deploy. We already block in other circumstances as well, e.g. if you have a MaxConnectionsPerServer set, we'll block waiting for an available connection for sync operations, rather than throwing, so not throwing here is consistent with that, too. This is different from the base Send/SendAsync methods, where in general not overriding a relevant sync method in the handler chain will deterministically fail; on top of that, all of our implementations shipped "in the box" override appropriately.
There was a problem hiding this comment.
I guess my original concern will get addressed with the proper implementation of #44876, and you're reasoning makes sense here. So thanks.
ghost
locked as resolved and limited conversation to collaborators
HTTP/1.1 support with sync requests currently doesn't work when a ConnectCallback is specified, even though a developer who wanted to make synchronous requests could provide a synchronously-completing callback.
This also consolidates the connect logic across sync/async, avoids an extra delegate, etc.
Contributes to #44876
cc: @geoffkizer, @scalablecory, @ManickaP