Hi raffaeler,

The API web::websockets::client::websocket_client::config() just returns the config object used during the creation of the client. It will not be updated to reflect the headers sent by the server.

I don't think we currently expose an API to access the HTTP headers. However, the library we build on (websocket++) does have this functionality: get_response_header(). You just need to get at the connection_ptr object stored in the implementation class here.

This will require some source code changes, but a clean API for fetching the underlying connection_ptr would be great to have. Please consider submitting a pull request for any modifications you find useful here :).

Hi ras,
thank you for your answer.

1. The headers behavior:
   The headers behavior is quite odd as this works:
   client->config()->headers()->add(...);
   while this does not:
   auto headers = client->config()->headers();
   headers->add(...)
   While I do understand the technical reason, IMO the API should be shaped in order to avoid the wrong usage.
2. I can't find the connection_ptr at that link. Do you mean «connection_hdl»?
3. The absence of the response header sounds really incredible. This absence is the same mistake done inside the .NET Framework... the only two implementations around that are missing this.
   The lack of the response headers does not allow all the scenarios where you need to know from the server the real and unique connection identifier "Sec-WebSocket-Accept". Any other 'application defined' id would require additional roundtrips and would be out of the RFC standard.
   Furthermore there are many other headers that are needed in all the scenarios where the websocket connection happens after an HTTP conversation.

While I could make a pull request for exposing the response headers, it would take more time (as I don't know anything about the details of the implementation, nor I would be able to build for all the supported platforms.

1. Hmm. This shouldn't work; the method signature is const websocket_client_config& config() const so you should get an immutable object out. In the second case listed, you're getting bit by auto, which will make a copy by default. Try using auto&& there and you should get the same behavior as the first case.
2. Yes, good catch 👍. connection_hdl is the one, though you may need to "upgrade" it to a connection_ptr to use get_response_header() (see here for an example).
3. As stated before, I definitely agree this is something that should be supported on all platforms where we use Websocket++. Even if you only can test for your platform, I would still encourage you to submit the PR.

Hi. Did anything come of this? I would also like to get at the websocket_client response header somehow ...

Nope. You have three choices:

1. use Websocket++ directly
2. change your protocol so that you don't need those headers
3. make yourself the change to expose the headers and submit a PR
   I picked the choice number 2.