-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Expose ClientWebSocket Upgrade Response Headers #28331
Comments
Hey @Yucked! Do you mind clarifying what you mean by "Response headers after ws handshake was completed"? The headers on the 101 switching protocols response, or something else? |
Hey @rmkerr I was following this guide to implement resuming: https://github.com/Frederikam/Lavalink/blob/feature/resume/IMPLEMENTATION.md#resuming-lavalink-sessions And in it, it says:
So, I thought perhaps they meant I should check my headers after doing Perhaps something similar to this: websocket-client/websocket-client#161 ? I'm sorry if I'm being extremely vague 😭 |
No problem! That info does help. Essentially what that is asking for is the last set of HTTP headers sent by the server before switching over to the WebSocket protocol. Unfortunately it doesn't look like we currently expose that information. We do verify that a few headers required by the WebSocket protocol are included, but we don't look at any others: Adding the ability to review those headers does seem reasonable, but it would probably require an API change. Usually we try to make sure there's interest in that kind of change before adding the feature, so I'll leave this issue up for that purpose. |
Omg, thank you! |
Hey. Just wondering how much interest is needed to get this in core 3.0? |
I read through the guide but it asks to open an issue first then wait for it to get approved. Should I make another issue on the same topic, wait for it to get approved then make a PR or just use this issue and open a PR? |
@Yucked you can put your API proposal to the top post here. |
I've updated my post but unsure if the suggestion covers all areas that may be affected by the change. The only changes I can think of are:
|
Triage: We need proper API proposal - see API process for examples. |
@karelz Should I open a new issue for API Proposal? |
@Yucked we can do it here - ideally, please edit top post (you can keep original text in separate section for history) |
Just wanted to check on the status of this and what would be needed to make it move forward. We have a similar use case where we're sending a bearer token, setting it in the handshake response header and we need to be able to read it on the client. |
Any update on this, is there any possibility to read a response headers & response status code in the client side. |
No update, it didn't make the cut for 6.0. |
Just wanted to check on the status of this and what would be needed to make it move forward. We also require a client (ClientWebSocket) to have the ability to access the response headers returned by the server in the handshake response on connection. In our project, the server uses this mechanism to inform the client of the sub-protocol version that will be used during subsequent communication. |
This has been addressed by the new APIs added in #25918 (comment) (exposed status code and headers). |
Summary:
The API proposal comes after I was required to read response headers after making a WS handshake. Currently there is no way to see what response headers were returned after connecting to a WS server.
Rational & Usage:
For my use case, the current usage would be to figure out if a session was resumed by reading the response headers after re-establishing a WS connection.
Here is where the use case is properly described: https://github.com/Frederikam/Lavalink/blob/master/IMPLEMENTATION.md#resuming-lavalink-sessions
Further more, it can allow people to read any custom headers sent in response.
Proposed API:
Expose a property called Headers in ClientWebSocket/WebSocket class.
And where headers are validated: https://github.com/dotnet/corefx/blob/master/src/System.Net.WebSockets.Client/src/System/Net/WebSockets/WebSocketHandle.Managed.cs#L181-L183
The
_headers
can be set once the required headers are validated.Original Post:
Hi! Pardon me if I opened the issue in the wrong repo.
I was wondering if there was a way to get response headers after ws handshake was completed.
Something like
WebSocketReceiveResult.Headers
or similar.Not sure if I'm looking in the right place. Any help will be appreciated.
Cheers!
The text was updated successfully, but these errors were encountered: