Expose ClientWebSocket Upgrade Response Headers

[Yucked]

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.

        public HttpResponseHeaders Headers
        {
            get
            {
                if (_headers == null)
                    throw new NullReferenceException("WebSocket connection hasn't started yet.");

                return _headers;
            }
        }

        private HttpResponseHeaders _headers;

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.

                ValidateHeader(response.Headers, HttpKnownHeaderNames.Connection, "Upgrade");
                ValidateHeader(response.Headers, HttpKnownHeaderNames.Upgrade, "websocket");
                ValidateHeader(response.Headers, HttpKnownHeaderNames.SecWebSocketAccept, secKeyAndSecWebSocketAccept.Value);

                _headers = response.Headers;

---

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!

[rmkerr]

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?

[Yucked]

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:

You can tell if your session was resumed by looking at the handshake response header Session-Resumed which is either true or false:
Session-Resumed: true

So, I thought perhaps they meant I should check my headers after doing (await ClientWebSocket.ConnectAsync()).Headers? but there is no such thing.

Perhaps something similar to this: websocket-client/websocket-client#161 ?

I'm sorry if I'm being extremely vague 😭

[rmkerr]

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:
https://github.com/dotnet/corefx/blob/adb4d48fe65d48b6dd1c2ff15c8a60e5f96bf266/src/System.Net.WebSockets.Client/src/System/Net/WebSockets/WebSocketHandle.Managed.cs#L175-L183

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.

[Yucked]

Omg, thank you!

[Yucked]

Hey. Just wondering how much interest is needed to get this in core 3.0?

[rmkerr]

I'm not sure. @karelz, this ask would require us to expose a new property. How much interest would we need to make that kind of change?

We do take contributions though -- if you are interested, you can try to get the change through API review yourself. That process is detailed here.

[Yucked]

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?

[karelz]

@Yucked you can put your API proposal to the top post here.
Be warned: We're a bit under water, so no guarantee we will be able to help it push through into 3.0 ... but if hte API design is good and if it makes sense, we are definitely interested long-term (post-3.0), and maybe it will make it even earlier ... who knows ...

[Yucked]

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:

• Returning the response headers in connect async methods
• Reflect the change on ClientWebSocket's ConnectAsync method

[karelz]

Triage: We need proper API proposal - see API process for examples.

[Yucked]

@karelz Should I open a new issue for API Proposal?

[karelz]

@Yucked we can do it here - ideally, please edit top post (you can keep original text in separate section for history)