Sec-WebSocket-Protocol header missing in Upgrade response

[pitti98]

This causes chrome, and probably other webkit-based browsers, to fail the ws connection with an error 1006.

fix: add a line to the http_reply call in websock_accept()

"Sec-WebSocket-Protocol: sip\r\n"

[sreimers]

Can you provide more details about your patch, at best a complete diff or with file and line number.

[pitti98]

Here you go:

diff --git a/src/websock/websock.c b/src/websock/websock.c
index 710f697..6a933af 100644
--- a/src/websock/websock.c
+++ b/src/websock/websock.c
@@ -542,6 +542,7 @@ int websock_accept(struct websock_conn **connp, struct websock *sock,
                         "Upgrade: websocket\r\n"
                         "Connection: Upgrade\r\n"
                         "Sec-WebSocket-Accept: %H\r\n"
+                        "Sec-WebSocket-Protocol: sip\r\n"
                         "\r\n",
                         accept_print, &key->val);
        if (err)

[sreimers]

Proto is not supported currently, I just opened a PR, this introduces a new proto specific api:

websock_accept_proto(connp, "sip",....);

[pitti98]

As far as I see, the Sec-WebSocket-Protocol header is mandatory in both the request and the 101 response, so the functions without a protocol will never be valid, right?

Edit:
Hmm, apparently the original rfc6455 says both are optional.

The source I found that mentions the header is
https://developer.mozilla.org/en-US/docs/Web/HTTP/Protocol_upgrade_mechanism
which says:
"The first one that is supported by the server will be selected and returned by the server in a Sec-WebSocket-Protocol header included in the response."

This sounded like it is not optional.

But apparently it is. So nevermind.

[pitti98]

That pull request just adds new functions, but transp.c/http_req_handler() needs to call the new one or it still won't work.