9487a157ab
After this commit, this crate will support using TLS streams in a half-closed state. Note that the TLS 1.3 spec in RFC 8446 says this should be supported: ``` Each party MUST send a "close_notify" alert before closing its write side of the connection, unless it has already sent some error alert. This does not have any effect on its read side of the connection. Note that this is a change from versions of TLS prior to TLS 1.3 in which implementations were required to react to a "close_notify" by discarding pending writes and sending an immediate "close_notify" alert of their own. That previous requirement could cause truncation in the read side. Both parties need not wait to receive a "close_notify" alert before closing their read side of the connection, though doing so would introduce the possibility of truncation. ``` https://tools.ietf.org/html/rfc8446#page-87 The `rustls` crate raises such a clean closure of a [`ClientSession`](https://docs.rs/rustls/0.18.0/rustls/struct.ClientSession.html#impl-Read) or [`ServerSesson`](https://docs.rs/rustls/0.18.0/rustls/struct.ServerSession.html#impl-Read) read-side with `ErrorKind::ConnectionAborted`. This crate's `TlsState` struct already encodes support for the half-closed states `TlsState::ReadShutdown` and `TlsState::WriteShutdown`, in addition to `TlsState::FullyShutdown`. However, the current behavior of the `AsyncRead` implementation is that it unconditionally shuts-down the write-half of a connection after the read-half closes cleanly with `ErrorKind::ConnectionAborted`. This change removes the `stream.session.send_close_notify()` and `this.state.shutdown_write()` calls from `poll_read()`. Note that `stream.session.send_close_notify()` is still called in `poll_shutdown()`, which the application calls to cleanly shutdown the write-half. I highly suspect the logic of this can be simplified and cleaned up further. Minimally, the edited match statement now has two identical branches which could be combined into one. Additionally, perhaps the `Stream` implementation should simply return `Ok(0)` for this case in its implementation of [`tokio::io::AsyncRead`](https://docs.rs/tokio/0.2/tokio/io/trait.AsyncRead.html), since that's the defined way to indicate clean closure with EOF from `AsyncRead`. However, I want to make the minimal changes and have them reviewed for logical correctness first. Co-authored-by: Braden Ehrat <braden@cloudflare.com> |
||
|---|---|---|
| .github/workflows | ||
| tokio-native-tls | ||
| tokio-rustls | ||
| .gitignore | ||
| Cargo.toml | ||
| LICENSE | ||
| README.md | ||
Tokio Tls
Overview
This crate contains a collection of Tokio based TLS libraries.
Getting Help
First, see if the answer to your question can be found in the Guides or the API documentation. If the answer is not there, there is an active community in the Tokio Discord server. We would be happy to try to answer your question. Last, if that doesn't work, try opening an issue with the question.
Contributing
🎈 Thanks for your help improving the project! We are so happy to have you! We have a contributing guide to help you get involved in the Tokio project.
Related Projects
In addition to the crates in this repository, the Tokio project also maintains several other libraries, including:
-
tokio: A runtime for writing reliable, asynchronous, and slim applications with the Rust programming language. -
tracing(formerlytokio-trace): A framework for application-level tracing and async-aware diagnostics. -
mio: A low-level, cross-platform abstraction over OS I/O APIs that powerstokio. -
bytes: Utilities for working with bytes, including efficient byte buffers.
Supported Rust Versions
Tokio is built against the latest stable, nightly, and beta Rust releases. The minimum version supported is the stable release from three months before the current stable release version. For example, if the latest stable Rust is 1.29, the minimum version supported is 1.26. The current Tokio version is not guaranteed to build on Rust versions earlier than the minimum supported version.
License
This project is licensed under the MIT license.
Contribution
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in Tokio by you, shall be licensed as MIT, without any additional terms or conditions.