You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 12, 2021. It is now read-only.
Running the client against an ancient (1.x) server fails with an exception reading "not a number" and not giving any clue as to what failed and why. This happens because in the 1.2 protocol the negotiation response did not have the TransportConnectTimeout property but the code parsing negotiation response expects all properties it reads to be present. We should ignore missing properties and allow the client to fail when checking the version of the protocol since it would give the user clear reason why the client cannot connect to the server.
The text was updated successfully, but these errors were encountered:
moozzyk
changed the title
Parsing negotiation response should not fail for missing values
Parsing negotiation response should not fail for missing properties
May 12, 2017
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Running the client against an ancient (1.x) server fails with an exception reading "not a number" and not giving any clue as to what failed and why. This happens because in the 1.2 protocol the negotiation response did not have the
TransportConnectTimeout
property but the code parsing negotiation response expects all properties it reads to be present. We should ignore missing properties and allow the client to fail when checking the version of the protocol since it would give the user clear reason why the client cannot connect to the server.Also see: https://blog.3d-logic.com/2015/05/20/signalr-native-client/#comment-18681
The text was updated successfully, but these errors were encountered: