The latest version of Openfire Bosh TLS will disconnect after a period of time. After using nginx TLS to connect to port 7070, the connection will not be disconnected again. Is there any problem with the TLS connection

pzhu1015 · October 9, 2023, 9:06am

guus · October 9, 2023, 2:44pm

Curious? This seems to be the Strophe library that is being used. What client is this?

How much time is there between each request?

pzhu1015 · October 10, 2023, 6:18am

We use strophe.js, which is the SSL port connected by Bosh. The request time is not fixed, and the heartbeat ping is once in 1 minute. Sometimes the ping sends no response, and sometimes iq or message. If we use nginx There is no problem converting port 7443 (SSL) to port 7070, but connecting directly to OpenFire 7443 can cause problems, which is strange

guus · October 10, 2023, 8:08am

Some time ago, I raised an issue with the Strophe project. It appears that an incorrect value is used for a timeout to restart a new connection. I do not see why it would be different for TLS vs non-TLS, but maybe it’s related.

github.com/strophe/strophejs

Using 'wait' instead of 'inactivity'?

opened 10:21AM - 18 May 21 UTC

guusdk

As per conversation in Converse's support MUC: it seems that Strophe is using th…e 'wait' attribute value where it should be using the 'inactivity' value of a BOSH session. From the XEP: > [7.1 Session Creation Request](https://xmpp.org/extensions/xep-0124.html#session-request) > (...) > * 'wait' -- This attribute specifies the longest time (in seconds) that the connection manager is allowed to wait before responding to any request during the session. This enables the client to limit the delay before it discovers any network failure, and to prevent its HTTP/TCP connection from expiring due to inactivity. > > (...) > [7.2 Session Creation Response](https://xmpp.org/extensions/xep-0124.html#session-response) > (...) > * 'inactivity' -- This attribute specifies the longest allowable inactivity period (in seconds). This enables the client to ensure that the periods with no requests pending are never too long (see Polling Sessions and Inactivity). > > (...) > I'm seeing the following behavior with Openfire where a session was established with these attributes in the response: ```secure="true" requests="2" inactivity="30" polling="5" wait="59" hold="1" ack="3554851751" maxpause="300" ver="1.6"``` Generally speaking, subsequent request seem to follow each-other immediately. Occasionally though, the response to a request isn't followed by an immediate new request (I don't know why). Instead, it takes, in this example, between 58 and 60 seconds for a new request to be made, as shown in this screenshot: ![image](https://user-images.githubusercontent.com/4253898/118634895-4f383c00-b7d3-11eb-993e-155e2b7b6fe7.png) (note the green line in the red box being interrupted). When the client eventually does create a new request, the server rejects it, as the inactivity period has passed. It _seems_ that the client is using the 'wait' period to generate a new request (why it didn't do so immediately might be a topic for a different issue). Instead, it probably _should_ have used the 'inactivity' period.

pzhu1015 · October 10, 2023, 8:57am

The issue you mentioned also has a status return value of 404, but my request response has no status value, and the responses are all empty, just like the request cannot be reached