80efd2eb19
xmpp-rs normally has the stance to get buggy implementations fixed rather than dropping checks. In this particular case I think this is not a good use of resources: - The disco#info feature var conveys no actual information: If an implementation replies properly to a disco#info query, it is already implied that it supports the protocol. - There are broken server implementations out there. A lot of them (all recent (>= 0.10 && < 0.13 AFAICT) Prosody IM instances). At this point in time, xmpp-rs is unable to query disco#info from MUCs hosted on such prosody versions, except by workarounds (such as the one removed in this diff). - XEP-0030 now features a note which reads: > Note: Some entities are known not to advertise the > `http://jabber.org/protocol/disco#info` feature within their > responses, contrary to this specification. Entities receiving > otherwise valid responses which do not include this feature SHOULD > infer the support. The case would be different if there were no (deployed) implementations which had this bug or if the bug actually had an effect on clients. Especially the latter is not the case though, as pointed out above. Hence, I conclude that this check is overly pedantic and the resources (time, emotional energy of dealing with bugs, punching patches through to stable distributions, etc. etc.) spent on getting this fixed would be better invested elsewhere. In addition, the workaround is extremely ugly and, even in the xmpp-rs implementation, has no test coverage. Without test coverage of such an implementation, it is bound to break in funny ways when xmpp-rs changes the strings of its error messages (which is something one might do even outside a breaking release).
59 lines
1.9 KiB
Rust
59 lines
1.9 KiB
Rust
// Copyright (c) 2023 xmpp-rs contributors.
|
|
//
|
|
// This Source Code Form is subject to the terms of the Mozilla Public
|
|
// License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
// file, You can obtain one at http://mozilla.org/MPL/2.0/.
|
|
|
|
use tokio_xmpp::connect::ServerConnector;
|
|
use tokio_xmpp::{
|
|
parsers::{
|
|
bookmarks,
|
|
disco::DiscoInfoResult,
|
|
iq::Iq,
|
|
ns,
|
|
private::Query as PrivateXMLQuery,
|
|
pubsub::pubsub::{Items, PubSub},
|
|
},
|
|
Jid,
|
|
};
|
|
|
|
use crate::Agent;
|
|
|
|
pub async fn handle_disco_info_result<C: ServerConnector>(
|
|
agent: &mut Agent<C>,
|
|
disco: DiscoInfoResult,
|
|
from: Jid,
|
|
) {
|
|
// Safe unwrap because no DISCO is received when we are not online
|
|
if from == agent.client.bound_jid().unwrap().to_bare() && agent.awaiting_disco_bookmarks_type {
|
|
info!("Received disco info about bookmarks type");
|
|
// Trigger bookmarks query
|
|
// TODO: only send this when the JoinRooms feature is enabled.
|
|
agent.awaiting_disco_bookmarks_type = false;
|
|
let mut perform_bookmarks2 = false;
|
|
info!("{:#?}", disco.features);
|
|
for feature in disco.features {
|
|
if feature.var == "urn:xmpp:bookmarks:1#compat" {
|
|
perform_bookmarks2 = true;
|
|
}
|
|
}
|
|
|
|
if perform_bookmarks2 {
|
|
// XEP-0402 bookmarks (modern)
|
|
let iq = Iq::from_get("bookmarks", PubSub::Items(Items::new(ns::BOOKMARKS2))).into();
|
|
let _ = agent.client.send_stanza(iq).await;
|
|
} else {
|
|
// XEP-0048 v1.0 bookmarks (legacy)
|
|
let iq = Iq::from_get(
|
|
"bookmarks-legacy",
|
|
PrivateXMLQuery {
|
|
storage: bookmarks::Storage::new(),
|
|
},
|
|
)
|
|
.into();
|
|
let _ = agent.client.send_stanza(iq).await;
|
|
}
|
|
} else {
|
|
unimplemented!("Ignored disco#info response from {}", from);
|
|
}
|
|
}
|