Conversations: RFC 7395 (WebSocket) support

[devurandom]

RFC 7395 aims to be a successor to BOSH (XEP-0124, XEP-0206, #129):

   To date, applications using the Extensible Messaging and Presence
   Protocol (XMPP) (see [RFC6120] and [RFC6121]) on the Web have made
   use of Bidirectional-streams Over Synchronous HTTP (BOSH) (see
   [XEP-0124] and [XEP-0206]), an XMPP binding to HTTP.  BOSH is based
   on the HTTP "long polling" technique, and it suffers from high
   transport overhead compared to XMPP's native binding to TCP.  In
   addition, there are a number of other known issues with long polling
   [RFC6202] that have an impact on BOSH-based systems.

[Natureshadow]

OK, but in what way is Conversations a BOSH-based client?

It uses XMPP over TCP as a native client.

[devurandom]

129 requests BOSH support, and in constrained environments connecting to HTTP(S) ports is a requirement to dig through (company, university, national, …) firewalls.

[eucalyptus30]

Hi,

Does anyone know if RFC 7395 (WebSocket) is now supported by Conversations ?
Or if BOSH (XEP-0124 & 0206) is supported ?

kind regards,
Euca

[andersruneson]

No, not supported.

[eucalyptus30]

Okay, thank you.

[rugk]

Still no news?

[iNPUTmice]

I have yet to encounter a firewall that is not tricked by XEP-0368 and port

1. So there are no plans to support websockets.

[QuentinC]

I can confirm that XMPP on port 443 (using an haproxy frontend for HTTPS / SSH / XMPP) has never been blocked for me !
Even behind strong firewalls !
The only thing that can block it would be a level 7 firewall, that would also block websockets too !

[devurandom]

One thing for consideration: XMPP servers configured for WebSockets on 443 are probably more common than such a server configured to listen on 443 for regular XMPP connections.

Also, the reason given for closing #129 was that WebSockets (RFC 7395) would be preferred over BOSH (XEP-0124, XEP-0206), which kind of suggested that support for either one was being considered.

Is this feature generally not wanted on Conversations, or would a pull request be accepted?

If it would, I think (without having had a look at Conversations' code) the path forward would be to provide an interface for the (dis)connection events, stream-level error handling and XEP-0198 handling, which seem to be the only things touched by RFC 7395. Afterwards the implementation of RFC 7395 should be pretty much straight forward, with the exception for see-other-uri (section 3.6.1) and the security considerations (section 6). Different protocols of the former can probably be simply ignored (Conversations does not support e.g. BOSH), while the latter might need to be examined with a closer look on how e.g. DANE can be used or whether the host-meta file can deliver information about the used certificate of the wss:// endpoint. Does this seem reasonable? Did I overlook something?

[iNPUTmice]

One thing for consideration: XMPP servers configured for WebSockets on 443 are probably more common than such a server configured to listen on 443 for regular XMPP connections.

You can always ask your operator to set this up.

Is this feature generally not wanted on Conversations, or would a pull request be accepted?

I think I would accept a PR if the code is rather contained, readable and maintainable.

[Lykos153]

@QuentinC Would you be willing to share your haproxy config? devurandom is right, this kind of setup seems to be quite uncommon yet

[QuentinC]

Yes absolutely, here is it:

frontend 443
    bind 0.0.0.0:443
    mode tcp
    default_backend vpn

    timeout client 1d

    tcp-request inspect-delay 5s
    acl acl_contentpresent req_len gt 0
    tcp-request content accept if acl_contentpresent


    acl acl_https req.ssl_hello_type 1
    use_backend https if acl_https

    acl acl_xmpp payload(0,5) -m bin 3c3f786d6c
    use_backend xmpp if acl_xmpp

    acl acl_ssh payload(0,7) -m bin 5353482d322e30
    use_backend ssh if acl_ssh

backend xmpp
    mode tcp
    server xmpp 127.0.0.1:5222

backend https
    mode tcp
    server https 127.0.0.1:8443

backend vpn
    mode tcp
    server vpn 127.0.0.1:1194

backend ssh
    mode tcp
    server ssh 127.0.0.1:22

You will have to move the https server to port 8443 (haproxy will bind the port 443).

In this configuration haproxy is always in TCP mode. This means that HTTPS is managed by the web server.

[Lykos153]

Thank you very much!

[gerritsangel]

One advantage for using websockets might be that it should be easier to proxy. If you are using a shared hoster or your 443 port is already blocked by your web server, it should be relatively simple to setup a reverse proxy to a XMPP server. Additionally, SSL termination can then be done in the web server instead of the XMPP server.

Basically like the haproxy configuration above, just for simple users :)

[mightyBroccoli]

Are there any future plans to implement bosh and / or websocket? Since prosody will support websocket nativly with the new release, and ejabbered able to use this Conversations would only profit from this imho.