Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-50387

QWebSocketServer subprotocols



    • Type: Bug
    • Status: Closed
    • Priority: Not Evaluated
    • Resolution: Duplicate
    • Affects Version/s: 5.6.0 Beta
    • Fix Version/s: None
    • Component/s: WebSockets
    • Labels:


      The QWebSocketServer never sends back the Sec-WebSocket-Protocol header which should include a list of application level subprotocols implemented by the server application. It is stated in the documentation of QWebSocketServer that it supports version 13 of web socket protocol.

      The https://tools.ietf.org/html/rfc6455 states that if the client specifies a protocol in Sec-WebSocket-Protocol, the server MUST send back the same protocol name if it supports it during handshake. The missing header in the response means that the server doesn't support the protocol and client socket cuts the communication. See the excerpt from the spec:

      "if the server does not agree to any of the client's requested subprotocols, the only acceptable value is null. The absence of such a field is equivalent to the null value (meaning that if the server does not wish to agree to one of the suggested subprotocols, it MUST NOT send back a |SecWebSocket-Protocol| header field in its response".

      I am registering this as a bug because of the complience problem with the version 13 of web socket protocol.

      However, the complience itself is not an issue. The practical implications are more serious - the QWebSocket server is not usable in most cases. It doesn't work with browsers, libraries like autobahn-js and other third-party web socket based implementations. It should not even work with it's own QWebSocket object as it now allows to specify http handshake headers via QNetworkRequest (nice and flexible solution btw.).

      Ironically, the functionality is already implemented in QWebSocketHandshakeResponse. It is just not accessible via QWebSocketServer public API. There is already a method called supportedProtocols() in QWebSocketServerPrivate class but it returns an empty list of protocols.

      It looks to me as an easy thing to do just give a user opportunity to specify non-empty list of protocols. I can imagine a method setSupportedProtocols(QStringList).

      Would it be possible, please?

      Thank you


          Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.



              kurt.pattyn Kurt Pattyn
              mfojtak Michal Fojtak
              0 Vote for this issue
              3 Start watching this issue



                  Gerrit Reviews

                  There are no open Gerrit changes