Potentially breaking change in your dependency - ServerCertificateCustomValidationCallback

[karelz]

We plan to release new System.Net.Http package which will break one API you use HttpClientHandler.ServerCertificateCustomValidationCallback - (usage in your code). The reason is that the package causes a lot of grief to .NET developers (see https://github.com/dotnet/corefx/issues/11100), we have to revert the source code back to 4.6 code and there is no simple way how to implement this property correctly in that code base.

The breaking change (more details in https://github.com/dotnet/corefx/issues/11100 - top-most post, section 'Impact of the change - Breaking changes'):

.3. HttpClientHandler. ServerCertificateCustomValidationCallback (introduced in System.Net.Http 4.1)

• New behavior: Works fine, except that the first parameter of type HttpRequestMessage is always null
• Workaround: Use ServicePointManager.ServerCertificateValidationCallback

Consul NuGet package is one of 4 NuGet packages directly affected by the breaking change in the APIs. Can you please assess if your library is affected and act accordingly?

Thank you and sorry for the inconvenience!
If you have any questions, please let us know.
cc @davidsh

[highlyunavailable]

Wow, thank you so much for submitting an issue about this!

The reason it was changed to use ServerCertificateCustomValidationCallback is that ServicePointManager.ServerCertificateValidationCallback didn't exist in .NET Core at the time at all if I recall correctly. :)

No changes are required, since this specific usage in this library's code has been obsoleted and a null first parameter is totally acceptable in this instance. It's a very minor part of the API - I'd say the upstream System.Net.Http change shouldn't materially affect this.

Thanks again!

[karelz]

Happy to hear that, thanks a lot for quick verification!