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

A clear and concise description of what the problem is - e.g. "I'm always frustrated when [...]"

On the Dialer, I need to use a custom NetDial method for TLS connections to be able to use some advance authentication methods like Mutual TLS using a client key from a Hardware Security Module (HSM). I have some go code wrapping OpenSSL that does the TLS dialing, including the handshake.

This works fine for regular https requests by setting this dial function as DialTLS for net/http.Transport.

The problem in gorilla/websocket is that the current Dialer interface only supports setting one pair of dial methods (NetDial and NetDialContext) which is used both for http and https connections. Later, for https a handshake is performed using TLSClientConfig, but in my case tls.Config fields are not enough to do the handshake, code here.

Describe the solution you'd like

What would the feature look like? How would it work? How would it change the API?

My suggestion is to have two pair of dial functions, NetDial + NetDialContext, and NetDialTLS + NetDialTLSContext. The latter pair would be used on wss/https connections. To avoid unexpected behavior when setting TLSClientConfig, if either NetDialTLS or NetDialTLSContext are set the code would assume that the TLS handshake has been performed there and TLSClientConfig can be ignored.

This API change would be completely backwards compatible, and it will better mimic the API of net/http.Transport (doc here).

I do have a working code for exact this API change that I am suggesting. I want to add some tests before submitting a PR. In the meanwhile, any feedback is welcome 😃

Describe alternatives you've considered

Are there alternatives you've tried, and/or workarounds in-place?

My workaround was to force the url to passed to Dial be ws, so that this specific block is skip... However this only works on certain circumstances and it is very hacky.