-
Notifications
You must be signed in to change notification settings - Fork 5.2k
Throw on incompatible WebSocket options #74473
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Tagging subscribers to this area: @dotnet/ncl Issue DetailsThere were 3 issues around reusing the shared handler:
I changed the logic so that we now hold 2 shared handler instances: one for "no proxy" and one for "default proxy". This resolves problem nr. 2. To mitigate problem 3, I changed the default While I was making these changes, I also avoided the For #74416, I added a simple check for any options that can't be honored when using a custom invoker instance, and we now throw an
|
/azp run runtime-libraries-coreclr outerloop |
Azure Pipelines successfully started running 1 pipeline(s). |
It seems that outerloop hit the same issue #74450 did... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks!
@stephentoub could please take a look at this one given that it concerns client sharing/caching? |
0722b7e
to
dcc51fc
Compare
/azp run runtime-libraries-coreclr outerloop |
Azure Pipelines successfully started running 1 pipeline(s). |
Updated the PR to remove all of the pooling logic. This is now just adding options validation and test changes. |
src/libraries/System.Net.WebSockets.Client/src/Resources/Strings.resx
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.WebSockets.Client/src/Resources/Strings.resx
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Product changes LGTM
/backport to release/7.0 |
Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/2981306574 |
dotnet#74473 had a change where we started adding a client certificate that is not supported on apple mobile platforms. This lead to an unhandled exception in the MemberData setup of ConnectAsync_CustomInvokerWithIncompatibleWebSocketOptions_ThrowsArgumentException and resulted in an app crash. Addresses dotnet#75307
…75344) #74473 had a change where we started adding a client certificate that is not supported on apple mobile platforms. This lead to an unhandled exception in the MemberData setup of ConnectAsync_CustomInvokerWithIncompatibleWebSocketOptions_ThrowsArgumentException and resulted in an app crash. Addresses #75307
#74473 had a change where we started adding a client certificate that is not supported on apple mobile platforms. This lead to an unhandled exception in the MemberData setup of ConnectAsync_CustomInvokerWithIncompatibleWebSocketOptions_ThrowsArgumentException and resulted in an app crash. Addresses #75307
…75423) Backport of #75344 to release/7.0 #74473 had a change where we started adding a client certificate that is not supported on apple mobile platforms. This lead to an unhandled exception in the MemberData setup of ConnectAsync_CustomInvokerWithIncompatibleWebSocketOptions_ThrowsArgumentException and resulted in an app crash. Addresses #75307
Fixes #74415
Fixes #74416
For #74415, we now throw if HTTP/2 has been requested but a custom invoker wasn't specified.
For #74416, I added a simple check for any options that can't be honored when using a custom invoker instance, and we now throw an
ArgumentException
.The only exception is the default
Proxy
- we don't throw if the user doesn't overwrite it (as that would impact all default use cases). Given thatSocketsHttpHandler
shares the same default (default proxy is used unless explicitly disabled), I don't think this is a big deal.