Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reading the headers in a websocket client #4

Open
raffaeler opened this issue Oct 13, 2015 · 5 comments
Open

Reading the headers in a websocket client #4

raffaeler opened this issue Oct 13, 2015 · 5 comments

Comments

@raffaeler
Copy link

Hi,
I am trying to read the headers right after the connect() in a websocket client app (rest-sdk 2.6).
auto config = client->config();
auto headers = config.headers();

The connect was successful, but the headers are always empty even if I can see them from wireshark.

As an additional information, I can't even see the server name (by default I understood that it should show up).
auto server_name = config.server_name();

My final target is to access the "Sec-WebSocket-Accept" string which should be used as an unique identifier of the connection.

Thank you

@ras0219-msft
Copy link
Contributor

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 :).

@raffaeler
Copy link
Author

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.

@ras0219-msft
Copy link
Contributor

  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.

@petke
Copy link

petke commented Nov 27, 2016

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

@raffaeler
Copy link
Author

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.

GerHobbelt pushed a commit to GerHobbelt/cpprestsdk that referenced this issue Mar 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants