Client side get_subprotocol() does not get populated

[JeffDavie]

I believe there may be a bug in the subprotocol capability. I am able to do the following: Client:

add_subprotocol("proto_a")
add_subprotocol("proto_b")
connect()

The request is similar to:

GET / HTTP/1.1
Connection: Upgrade
Host: localhost:9002
Sec-WebSocket-Key: AAAAAAAAAAAAAAAAAAAAAA==
Sec-WebSocket-Protocol: proto_a, proto_b
Sec-WebSocket-Version: 13
Upgrade: websocket
User-Agent: WebSocket++/0.7.0

Server onValidate():

get_requested_subprotocols()
select_subprotocol("proto_a")

The response is similar to:

HTTP/1.1 101 Switching Protocols
Connection: upgrade
Sec-WebSocket-Accept: ICX+Yqv66kxgM0FcWaLWlFLwTAI=
Sec-WebSocket-Protocol: proto_a
Server: WebSocket++/0.7.0
Upgrade: websocket

Client onOpen(): get_subprotocol() returns an empty string. I would expect that get_subprotocol() would return "proto_a". I believe this could be worked around by parsing the header in the onOpen() handler, but I think the intent of the interface was that this information is already parsed.

In impl/connection_impl.hpp, handle_http_read_response() performs validation on the response, negotiates the extensions, but does not parse the negotiated response of the subprotocol.

[zaphoyd]

Yes, this is broken. The subprotocol should be available to the client via get_subprotocol().