remove reqwest unit tests, dev-dependency #43
Merged
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.
Previously the
verification
mod had a unit test,can_verify_server_cert
, that ensured using the platform verifier withreqwest
could be done without error.The reason for this was that the
reqwest
API consumes custom verifiers to use with a Rustls client config as&dyn Any
inputs, and then downcasts at runtime to the requiredArc<dyn ServerCertVerifier>
- this means that ifrustls-platform-verifier
uses a different Rustls version thanreqwest
a runtime panic would occur.However, having this unit test in place means we can't update
rustls-platform-verifier
to a new Rustls release until thereqwest
ecosystem first updates. This is suboptimal, asreqwest
itself has many dependencies that need similar updates.This commit removes the unit test. Ensuring the Rustls versions match should be handled by downstream consumers that have chosen to use
reqwest
. There are other libraries one might userustls-platform-verifier
with, and we shouldn't block useful updates to this crate onreqwest
. In general one already has to be careful about mixing/matching Rustls versions across dependencies, the fact thatreqwest
makes this a runtime concern is unfortunate, but not a great reason to avoid keeping this crate in sync with the rest of the 1st-party Rustls ecosystem.