Closed jbr closed 5 months ago
I hope that futures-rustls and tokio-rustls keep isomorphic in implement to reduce maintenance costs.
You can refer to this to implement it. https://github.com/rustls/tokio-rustls/pull/44
Specifically you mean adding a variant instead of using an option? Will do.
Why don't these crates share code if they're intended to be largely identical? Or have one crate and enable the async traits with a feature flag? Or at the least keep them in a shared workspace folks remember to update both?
I also believe there's a bug in the other implementation, in that it doesn't check if the alert returns WouldBlock and return pending. Should I PR that over there?
Switched to using a MidHandshake::SendAlert variant instead of a MidHandshake::Error { alert: Option<AcceptedAlert>,.. }
@quininer @djc Is this PR good to go? I believe it tracks all of the changes that have been made in tokio-rustls for rustls 0.23
There are some other changes in tokio-rustls (poll_shutdown, vectored write), would you like to work on it in this PR?
I'll take a look tonight.
Thank you!
This PR is an attempt at updating futures-rustls for rustls 0.23.
aws-lc-rs
to track rustls' default. (https://github.com/rustls/tokio-rustls/pull/50 for parity)fips
andlogging
features so crates don't need to depend on rustls just to enable those features without using rustls directly in code (https://github.com/rustls/tokio-rustls/pull/49 for parity)Option<Error, AcceptedAlert>
on LazyConfigAcceptor in order to send the AcceptedAlert, tracking the changes in https://github.com/rustls/tokio-rustls/pull/48pub(crate) common::SyncWriteAdapter
and uses it instead of an identical function-localWriter
type, tracking the changes in https://github.com/rustls/tokio-rustls/pull/44SyncReadAdapter
instead of an identical function-localReader
type tracking the changes in https://github.com/rustls/tokio-rustls/pull/44Let me know if you'd like me to split any of these out into distinct PRs or to back them out of this PR.