Sec-WebSocket-Protocol about ws HOT 6 CLOSED

I mean something like this:

func upgrade(conn net.Conn) error {
    var negotiatedBinary bool
    _, err := (ws.Upgrader{
        OnBeforeUpgrade: func() (ws.HandshakeHeader, error) {
            if !negotiatedBinary {
                return nil, ws.RejectConnectionError(
                    ws.RejectionCode(403),
                )
            }
            return
        },
        Protocol: func(p []byte) bool {
            if bytes.Equal(p, []byte("binary2")) {
                negotiatedBinary = true
                return true
            }
            return false
        },
    }).Upgrade(conn)
    return err
}

from ws.

Hi @navossoc,

From the RFC:
6. If the response includes a |Sec-WebSocket-Protocol| header field
and this header field indicates the use of a subprotocol that was
not present in the client's handshake (the server has indicated a
subprotocol not requested by the client), the client MUST Fail
the WebSocket Connection.

from ws.

In other words you can not “enforce” to use some subprotocol which client does not know. This mechanism is intended to make both sides of connection agreed on the subprotocol.

from ws.

Also, if your client knows how to deal with both binary and binary2 subprotocols, they could both passed as a comma separated list (ordered be preference) during handshake.

from ws.

Thanks for your answer, but I'm still not sure if this is totally accurate.
I know, if the client can't handle the subprotocol it can't be enforced, but at least the connection should not be completed.

For example, this websocket server:

wscat --connect wss://upp203a.ig.com/lightstreamer (fail/403) (I meant this case, server expect a subprotocol, client didn't sent any)
wscat --connect wss://upp203a.ig.com/lightstreamer -s randomprotocol (fail/403) (wrong subprotocol, ok, already handled by gobwas/ws)
wscat --connect wss://upp203a.ig.com/lightstreamer -s js.lightstreamer.com (succeed/101)

You can check it here: https://www.ig.com/us

In this case, the client didn't sent a Sec-WebSocket-Protocol as per RFC it MAY send it or not. So it is ok.
Now, the server only knows how to speak subprotocol js.lightstreamer.com so it send back a 403.

That is what I was trying to achieve.

To be honest, I believe I didn't read in the RFC a case like this.

Do you know any other websocket servers that are using a subprotocol? I'll try to find more tomorrow for testing.

from ws.

It looks like OnBeforeUpgrade callback will work for you – negotiated subprotocol could be checked there and appropriate error may be returned.

from ws.