Before this, a stream error would not be readable by user code, as the
`recv_features()` function would not even attempt to parse it. This
change allows application code to react to stream errors which are
received before stream features are received.
skip-changelog, because there's no release with the xmlstream module
yet.
This provides a clear and consistent interface for selecting TLS-related
features on both (xmpp and tokio-xmpp) crates. All feature checks have
been revamped. All working combinations have been tested (including a
connectivity test + --all-features docs build) using:
```
set -xeuo pipefail
features=(aws_lc_rs ring ktls,aws_lc_rs ktls,ring aws_lc_rs,ring aws_lc_rs,ring,ktls native-tls rustls-any-backend)
export RUSTFLAGS=" -D warnings"
cargo test --no-default-features
cargo test
for feature in ${features[@]}; do
echo ">>> BUILDING with $feature" 2>&1
# Running code or building examples cannot succeed with rustls-any-backend.
features="starttls,$feature"
if [ "$feature" != 'rustls-any-backend' ]; then
if ! cargo test --no-default-features --features="$features"; then
echo ">>> BUILD FAILED for tls feature set: $features" >&2
exit 1
fi
set +e
timeout -sINT -p -k 2 3 cargo run --no-default-features --features="$features" --example keep_connection -- test@hub.sotecware.net "$(pass xmpp/test@hub.sotecware.net)"
status="$?"
set -e
if [ $status -ne 0 ]; then
echo ">>> keep_connection did not shut down cleanly! (status: $status)" >&2
exit 1
fi
else
if ! cargo build --no-default-features --features="$feature"; then
echo ">>> BUILD FAILED for tls feature set: $features" >&2
exit 1
fi
fi
done
RUSTDOCFLAGS="--cfg docsrs" RUSTFLAGS="--cfg xmpprs_doc_build" cargo +nightly doc -Zrustdoc-map --all-features
```
For this, we had to:
- Make the choice(s) of backend explicit in tokio-xmpp features
- Avoid picking a backend through transitive dependencies in xmpp
(reqwest->hyper->rustls).
In addition, we choose the default rustls backend by default and adapt
the examples so that they can cope with either situation.
This way, we don't end up with breakage if rustls is built with more
than one provider enabled. This can (and does) happen if a transitive
dependency (such as reqwest *hinthint*) depends on a specific,
non-default rustls backend.
The user may have to call some global rustls functions depending on the
exact feature set of rustls enabled. Hence, we have to expose it.
Concretely, if the user somehow ends up with more than one rustls
backend, they have to configure one of the backends as default backend
at startup.
The stream may have read some data already (such as the stream
header). When initially writing this code, I had missed that we do
actually also carry the parser state over: I misread the
AsyncReader::wrap(..) command as something like AsyncReader::new, i.e.
starting off with fresh parser state, so I assumed that we need a fresh
XmlLangStack, too.
This is wrong: `p` comes from `self.parser.into_inner()` above and is
the parser state, so we need to carry the lang stack along, as well.
This fixes:
```
thread 'tokio-runtime-worker' panicked at […]/rxml-0.13.1/src/xml_lang.rs:87:13:
pop from empty XmlLangStack
```
happening during stream shutdown. The panic was first reported by
@ppjet6, so thanks for that and the keen eye.
skip-changelog, because the bug has not been released yet.
This is still far from being a full fix. Still, we can avoid the lang
attribute (by allowing discarding the `xml:lang` value via the feature
introduced a couple commits ago) and we can avoid emitting `xml:lang=""`
where no language was previously set using the mechanism introduced for
<message/> in 5172fb5e.
This function always appends to an existing string, so by passing it a
String directly we can avoid superfluous allocations.
Also tokio-xmpp was doing a bunch of &str to String for no reason around
there, let’s remove that too.
insecure-tcp requires the io-util feature of tokio, so let’s enable it
there.
Fixes this error:
5 | use tokio::{io::BufStream, net::TcpStream};
| ^^^^^^^^^^^^^ no `BufStream` in `io`
The Client::send_stanza method blocks on the stanza actually being sent
over the stream. Without this change, the method will never return
on streams without XEP-0198 Stream Management because `sm_state` is
then None and thus the StanzaToken's state is never advanced: it would
be stuck in Queued state.
In addition, a lack of advancement to Sent state may cause a deadlock on
XEP-0198-enabled streams if data is received so fast that the
frontend_tx mpsc::Sender in the stanzastream::Worker is filled up. In
such a case, the Worker cannot obtain a permit and will only service
writes. However, that will mean that no StanzaTokens can be advanced
beyond Queued state, because for that, reads need to be serviced (to
receive the SM acks).
If a burst of stanzas is then received while Client::send_stanza is
being awaited, send_stanza can only return if something reads from the
frontend mpsc in the meantime. We do not want to require user code to
drive the Client in full-duplex mode, hence this is a bug.
skip-changelog, because this fixes an unreleased feature.
Instead of having a second method to fetch channel-binding from the
TlsStream, do it directly in the connect() method, since after that we
don’t have enough information to fetch it any longer when using ktls.
This allows to use any serialisable type. The advantage is that moves
and clones are avoided (which would otherwise be needed to construct
e.g. a XmppStreamElement from a Stanza or Message).
