Details
-
Bug
-
Resolution: Duplicate
-
Not Evaluated
-
None
-
5.6.0 Beta
-
None
Description
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
Attachments
Issue Links
- is replaced by
-
QTBUG-38742 Add support for subprotocols
-
- Closed
-