-
Notifications
You must be signed in to change notification settings - Fork 24
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
Add RequestBuilder methods to accept invalid TLS #40
Conversation
I did some experiments with badssl.com, and I think that |
@@ -11,6 +11,16 @@ use url::Url; | |||
use crate::happy; | |||
use crate::{ErrorKind, Result}; | |||
|
|||
pub struct ConnectInfo<'u> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is nice! 👍
@sbstp I was thinking about this again and maybe we want to avoid adding nooks and crannies for all possible network scenarios to attohttpc's API, maybe we just need a public trait like
provide a default implementation using
This way we can remove the It would also allow third parties to avoid Happy Eyeballs if they do not want for whatever reason or to add request deadlines in any of the ways we discussed so far without making attohttpc itself much more complex. We would just need to provide documentation and example as guidance on how to do that using this trait. |
#41 is another thing that could be resolved using the API. |
What I had in mind for this library was more of a turnkey experience, similar to Python's requests. I think there's a finite and reasonable set of features that people might expect to see in a library like this. I'm not against offering lower level hooks that enable people to customize the library even more, but for now, I don't want to turn people away and tell them to just do it themselves. For instance to disable tls verification in requests you just set the |
No description provided.