EntityCapabilityManager should not assume that every client supports version 1.4 of XEP-0115


It appears that the EntCapsManager assumes that all clients use version 1.4 of the Client Capability XEP. Our client (and I bet a lot of others as well) do not use this version yet.

I think that the EntCapsManager should first check if 1.4 is used, before actually starting to poll clients. The XEP gives you this way to check for support:

An application can determine if the legacy format is in use by checking for the presence of the 'hash' attribute, which is REQUIRED in the current format.




Daryl Herzmann
October 22, 2015, 1:45 PM

Guus, Is this still an issue?

Guus der Kinderen
February 6, 2013, 7:57 PM

Removing the 'fix version' for all unresolved issues that were scheduled for version 7.8.2. We're releasing this version today - the remaining issues should be rescheduled later.

Guus der Kinderen
September 23, 2008, 2:45 PM

I've applied patch that prevents service discovery requests to be sent out to clients that support the legacy format. This will reduce the impact of the problem. Those clients didn't properly have their capabilities logged anyway, so there won't be a loss in functionality.

We still need to add support for legacy formatted client capabilities though.

Guus der Kinderen
September 23, 2008, 2:23 PM

As described about, this issue will cause a disco#info request to be sent out to clients that do not support the new format of XEP-0115. These disco#info requests will therefor fail. As EntityCapabilityManager does not remember that a particular client fails to correctly respond to a disco#info request (JM-1448), it will simply re-query the client when the next presence packet is being processed. That request will, of course, fail again. Rinse, repeat.

In one (20 minute) sample that I've taken, I've seen over 6 requests per second being send like this - all of them doomed to fail. This is an unacceptable amount of overhead on the server network, as well as on the (data link of the) clients (which is particularly bad if the client is installed on a mobile phone, which often have slow network connections and limited data plans).

There's a very easy workaround for preventing this behavior: make sure that EntityCapabilityManager does not process presence stanzas if they include client capabilities in legacy format. This is easily achieved by checking for the availability of the 'hash' attribute. Ignoring legacy formatted client capabilities corresponds with suggestions made by XEP-0115:

If a caps-processing application does not support the legacy format, it SHOULD ignore the 'ver' value entirely (since the value cannot be verified) and SHOULD NOT cache it, since the application cannot validate the identity and features by checking the hash.

The proper way of fixing this issue is described in the XEP as well, but will take more time to implement. Instead of the disco#info responses, the legacy formatted client capabilities should be cached as well. XEP-0115, section 13 'Legacy Format', says:

If a caps-processing application supports the legacy format, it SHOULD check the 'node', 'ver', and 'ext' combinations as specified in the archived version 1.3 of this specification, and MAY cache the results.




Guus der Kinderen