-
Notifications
You must be signed in to change notification settings - Fork 2
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
fix: Add TLS support, and allow changing TLS backend. #9
Conversation
65b72a6
to
671ec40
Compare
The workflow is failing due to We can either use I will take a look into how |
Thanks for opening this. I've been using this library exclusively for local development, so I hadn't been in a situation where I could encounter this issue. |
Simplest solution is going to be to just install the packages before testing. If anyone has the interest they can use a workspace and do a few tricks to optimize it. I have spent quite a bit of time trying to set up local instances to test around with the workflow but to no success. Meaning I can only test stuff in a debian docker container locally. |
It could be worth just sticking to 1 way of doing TLS so it doesn't rely on having a specific package installed. If I understand correctly, rustls lets us do that? |
Thats correct and definitely an option. However I think keeping the default reqwest TLS backend is a better idea as it is likely to get better testing. The native solution also is generally a battle hardened backend which is used widely in many applications. Either way its your choice. 👍 |
Default should do the trick, though I'm having trouble finding a list of required system dependencies for it across distros/operating systems. |
I agree that is a bit problematic. I would recommend reading seanmonstar/reqwest#2025 as they mention similar issues on the rustls side as well. When it comes to system dependencies the failed build does give out an appropriate error message for both dependencies in the case they are missing. It is also worth mentioning that most systems will not need an extra step anyway. This includes the older test image with Alpine. In short I think sticking with the default and providing options is the way to go considering both have various reasons to prefer one over the other. |
With the default features being disabled for the
reqwest
dependency in this commit 398e498, a scheme error is raised by the request client when sending any request withClientOptions.secure
set totrue
.This enables TLS support by default and allows changing the backend via features.