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
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The ClientWebSocket instance used by our MQTT/AMQP libraries already have a default remote certificate validation callback, so there is no need for us to define it as well. Simply leaving this field as null will make these libraries use their default implementation.
In addition, now that we aren't passing in a default value for this field every time, we don't have to worry about the .NET 472 case that #3328 had to work around.
IoT hub device client already had this behavior, but now the provisioning device client and the IoT hub service client do as well. This is why we only saw these .NET 472 test failures in our DPS tests (since no Hub service client operations use MQTT)
The ClientWebSocket instance used by our MQTT/AMQP libraries already have a default remote certificate validation callback, so there is no need for us to define it as well.
In addition, now that we aren't passing in a default value for this field every time, we don't have to worry about the .NET 472 case that #3328 had to work around.
IoT hub device client already had this behavior, but now the provisioning device client and the IoT hub service client do as well
The ClientWebSocket instance used by our MQTT/AMQP libraries already have a default remote certificate validation callback, so there is no need for us to define it as well. Simply leaving this field as null will make these libraries use their default implementation.
In addition, now that we aren't passing in a default value for this field every time, we don't have to worry about the .NET 472 case that #3328 had to work around.
IoT hub device client already had this behavior, but now the provisioning device client and the IoT hub service client do as well. This is why we only saw these .NET 472 test failures in our DPS tests (since no Hub service client operations use MQTT)
The ClientWebSocket instance used by our MQTT/AMQP libraries already have a default remote certificate validation callback, so there is no need for us to define it as well. Simply leaving this field as null will make these libraries use their default implementation.
In addition, now that we aren't passing in a default value for this field every time, we don't have to worry about the .NET 472 case that #3328 had to work around.
IoT hub device client already had this behavior, but now the provisioning device client and the IoT hub service client do as well. This is why we only saw these .NET 472 test failures in our DPS tests (since no Hub service client operations use MQTT)
What about HTTP calls?
Good question. The same behavior from the transport library is there ("if you don't set this callback, we have a default implementation for you"), but it looks like we are currently assuming we have an implementation, so I'll fix that
Should we remove the check that was added in #3328 ?
Yes. Looks like I forgot to commit that, so I've added that change now
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
timtay-microsoft
requested review from
drwill-ms,
abhipsaMisra,
andyk-ms,
brycewang-microsoft,
tmahmood-microsoft and
patilsnr
as code owners
The ClientWebSocket instance used by our MQTT/AMQP libraries already have a default remote certificate validation callback, so there is no need for us to define it as well. Simply leaving this field as null will make these libraries use their default implementation.
In addition, now that we aren't passing in a default value for this field every time, we don't have to worry about the .NET 472 case that #3328 had to work around.
IoT hub device client already had this behavior, but now the provisioning device client and the IoT hub service client do as well. This is why we only saw these .NET 472 test failures in our DPS tests (since no Hub service client operations use MQTT)