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