[FEATURE] Allow specifying an http.Client for initiating the websocket request

[BinaryFissionGames]

Is there an existing feature request for this?

• I have searched the existing feature requests

Is your feature request related to a problem? Please describe.

We are using gorilla/websocket in our library ((opamp-go)[https://github.com/open-telemetry/opamp-go]) for the implementation of the websocket transport. opamp-go can use either http or websocket transport.

A problem we've kept running into is that for the http transport, we can simply specify the http.Client and allow those connection settings to be used. However, for websockets, we can't use a specified http.Client, so we end up having to implement our own interface instead of just using the standard http.Client one.

Since websockets are implemented over http, I think it would make sense for us to be able to specify an http.Client to be used.

Describe the solution that you would like.

It would be nice if there was a way to pass an http.Client into the dialer, or maybe even have a separate dial function for it. This would make it possible to specify things like CheckRedirect and a http.RoundTripper that can allow for more standardized handling of the initial http connection.

Describe alternatives you have considered.

No response

Anything else?

No response

[mayankpmahajan]

@BinaryFissionGames I'm working on this issue and needed a clarification. So what you want basically is to transfer all the settings that additonal parameter http.Client brings (transport, timeout, JAR) to the upgraded connection?

[BinaryFissionGames]

@BinaryFissionGames I'm working on this issue and needed a clarification. So what you want basically is to transfer all the settings that additonal parameter http.Client brings (transport, timeout, JAR) to the upgraded connection?

What I would like is the initial http request that establishes the persistent connection to be made with the http.Client (I think just using the settings from it is equivalent).

[z3db0y]

+1 would like to see support for this, as it also allows reusing a keep-alive connection, for example making an HTTP and a WebSocket connection over a single proxy connection

also allows reusing a keep-alive connection

It's possible that some sever and proxy implementations allow reuse of a connection, but it's not something that's allowed by RFC 6455.

[z3db0y]

but it's not something that's allowed by RFC 6455

I haven't seen anything in the RFC that states a that a proxy connection may not be open and used prior to the socket request...

According to Section 4.1 in the RFC, opening a network connection is the first step in establishing a WebSocket connection. This implies that network connection was not used prior to establishing the WebSocket connection.

[aduong]

Furthermore, Section 5.5.1 in the RFC requires that the TCP connection is closed after the WebSocket connection is closed, so it would not be possible to reuse that TCP connection.