Comment 1 by jdnurmi@qwe.cc:

I've attached a patch I'm using currently;  It adds a *tls.Config to websocket.Dial;  It
may be nil for both ws and wss sockets (and will use the default configuration in the
latter if so).
I think this 'optional' parameter is the simplest way to add this functionality, though
I think being able to modify the 'default' tls.Config has merits as well.

Attachments:

1. ws.patch (1203 bytes)

Comment 2:

This would bring it up to 2 optional positional parameters, of 4.  And not next to each
other.  Kinda gross, imo.
I have a small vote towards making a new DialTLS, but I'll defer to the other Gophers. 
I'm not sure who owns websocket.

Comment 3:

ukai@google.com does

Comment 4 by ryanbressler:

I also ran into this issue. What I would really like is an exported function that
accepts a *Conn which could be from tls.Dial, net.Dial or wherever. You could almost
just export websocket.newClient but you would have to also export websocket.handshake.

Comment 5 by jdnurmi@qwe.cc:

I'm uninclined to have a strong opinion on how it _should_ be done, but as it is, .Dial
performs 'magic' based on the Scheme of the passed in URL;  The fact that this then
implies an unmodifiable tls.Config seems to be worse than having 2 optional parameters
-- especially if (for whatever reason) I don't trust the /etc/ssl/certs/... bundle for
my application.
So that is to say: If .Dial will magically upswing to TLS based on a potentially
user-specified parameter, I want to be able to control TLS parameters in one call;
  
- If Dial were re-formed to something like (host,port,resource,ws_origin,ws_protocols)
and a TLS version, then I'd be unconcerned by the magic, but by the length of the call.  
-  I also don't like the idea of having to be 'smart' if i'm accepting a user WS://URL
and make a different call if I have specific TLS/SSL needs;
- I'd consider it probably wrong to have a DialTLS with similar 'auto-sensing'  URL
behaviour, but an extra parameter for *tls.Config;  Esp., if DialTLS could create
a non-TLS connection by using a 'ws://' URL.
FWIW, the two protocol & origin parameters are not so much optional, as WS specific --
you don't _have_ to care what they are (tho Go kills an origin-less WS), but the
protocol considers them 'core' connection strings;
Ryans comment about allowing us to 'hijack' an existing net.Conn or http.ClientConn
would be a good thing to have regardless, and would've allowed (albeit with more work) a
similar end.

Comment 6:

Labels changed: added packagechange.

Status changed to HelpWanted.

Comment 7 by ukai@chromium.org:

To support new hybi protocol, I'm thinking to change websocket.Dial to
 websocket.Dial(url string, config *websocket.Config)
and
 type Config struct {
    Protocol []string
    Origin string
    Version string
    ...
 }
so, *tls.Config may be a member of Config.
I also think of exporting NewClient.
What do you think of?

Comment 8 by jdnurmi@qwe.cc:

Not sure what hybi is, but it seems pretty reasonable to me;
One thought though -- would it be better to use a *http.URL rather than parsing it
internally?  (Never been sure why so many functions that take URL's like strings myself,
since it's one more error to catch 'in-call')
Simultaniously, exporting a Handshake(*http.ClientConn, *proto.Config) might be useful .

Comment 10:

You can use websocket.DialConfig with config.TlsConfig
since weekly-2011-09-01

Comment 11:

Labels changed: added priority-later.

Comment 13:

If this is solved by DialConfig, shouldn't this issue be closed as Fixed? Unless I'm
missing something.

Comment 14:

Labels changed: added go1.3maybe.

Comment 15:

Labels changed: added release-none, removed go1.3maybe.

Comment 16:

Labels changed: added repo-net.

Comment 17:

This was fixed long ago: use DialConfig.

Status changed to Fixed.