It seems only to react on requests that have the Content-Type "text/plain" header, which is wrong.

I checked and current version from repository works as expected, it reacts even on:

OPTIONS / HTTP/1.1
Host:tigase.org

There was issue with earlier versions of 5.2.0, maybe even last beta version contained issue.

Hi Wojcik!,

I think you are right. The bug must have been both in ealier versions of 5.2.x and in 5.1 series, because these do not work with preflight. I actually think that you should release a new version of 5.1.x-stable to fix this problem.

But you are right about 5.2.0-beta2 (b3223) works fine with CORS.

I've been testing CORS preflight on:

• 5.1.x - beta something - Did not work

• 5.2.x-beta1 - Did not work

• 5.2.0-beta2 (b3223) - Worked!

Still some strange problems when I am using CORS vs. a proxy.

When using CORS which now works in 5.2.0-beta2 (directly on 5280 port on the server) my client keeps to be disconnected (404 invalid SID) every 10'th minute.

@

POST http://localhost:5280/http-bind/ 404 (Invalid SID) :5280/http-bind/:1

[15-08-2013 14:15:07] XMPPContoller.js: Strophe disconnecting Logger.js:15

[15-08-2013 14:15:07] XMPPContoller.js: Strophe disconnected Logger.js:15

[15-08-2013 14:15:07] XMPPContoller.js: Trying to reconnect. Connect iterations: 1 Logger.js:15

[15-08-2013 14:15:13] XMPPContoller.js: Strophe connecting Logger.js:15

POST http://localhost:5280/http-bind/ 404 (Invalid SID) :5280/http-bind/:1

[15-08-2013 14:25:26] XMPPContoller.js: Strophe disconnecting Logger.js:15

[15-08-2013 14:25:26] XMPPContoller.js: Strophe disconnected Logger.js:15

[15-08-2013 14:25:26] XMPPContoller.js: Trying to reconnect. Connect iterations: 2 Logger.js:15

[15-08-2013 14:25:33] XMPPContoller.js: Connecting Logger.js:15

[15-08-2013 14:25:33] XMPPContoller.js: Strophe connecting Logger.js:15

POST http://localhost:5280/http-bind/ 404 (Invalid SID) :5280/http-bind/:1

[15-08-2013 14:35:45] XMPPContoller.js: Strophe disconnecting Logger.js:15

[15-08-2013 14:35:45] XMPPContoller.js: Strophe disconnected Logger.js:15

[15-08-2013 14:35:45] XMPPContoller.js: Trying to reconnect. Connect iterations: 3 Logger.js:15

[15-08-2013 14:35:53] XMPPContoller.js: Connecting Logger.js:15

[15-08-2013 14:35:53] XMPPContoller.js: Strophe connecting Logger.js:15

@

This didn't happen when I was using a proxy for connecting to BOSH interface.

After examining the server log, I can see that there is an inactivity timer. Can this be set in the init.properties? something like basic-conf/bosh/inactivity=60 or?

It seems like it is triggered from the server side:

2013-08-15 14:41:55.280 [pool-2-thread-1] BoshSession.disconnected() FINEST: Setting inactivityTimer for 10: c11e4983-51ee-4a25-9819-60ca840ac8b2

PS: Sorry for all the updates on the issue. :-)

Updates are OK, I have no problems with that. In fact I appreciate all the details and information you provide.

There is a setting for the Bosh inactivity timer:

bosh/max-inactivity[L]=60

This, however, has some disadvantages, such as, if the user on the website closes the client (web browser) the server would know about it only after the timeout expires, so people may send messages to the user who is already offline. My suggestion is to keep the timeout short and make sure the web client reconnects quickly enough to not trigger the timeout.

I think inactivity of 60 seconds it a bad thing anyway. User would not see any messages, presences or anything when the web client is not connected to the server.

Hi Artur, you are right about the behaviour and a better fix might be to use the Attach instead of making all of the connection again.

That means save the SID, RID etc. as a cookie on the client and use attach to attach to the earlier session, if possible. I don't know if that will 'renew' the session on the server side, but I think I need to try it out.

Yes, we have used this technique to efficiently handle stuff like page reload. We save SID and RID in a cookie so we can recover last Bosh session from the cookie. More over, Tigase has something we call Bosh cache which keeps some of the data in the Bosh session like user's roster, contact presences, messages and even allows the web client to store other data such as properties of opened chat windows.

So, after the web page reload if the web client can reuse the SID/RID and successfully attach to the old Bosh session it can quickly reload all the data without going through authentication process again, there is no presences going back and forth.

However, this does not solve the problem with inactivity timeout running out. This only works if you attempt to reuse old Bosh session before the inactivity timeout expired.