A function to copy a tls.Config should probably be exposed in 1.8 because net/http could use it. Also, the current DialWithDialer function copies the config in order to set an SNI value, but that has a complex interaction if the Config is being used for serving. Maybe that's an unreasonable use-case but, if so, what's reasonable could be better documented.
The text was updated successfully, but these errors were encountered:
In Go 1.0, the Config struct consisted only of exported fields.
In Go 1.1, it started to grow private, uncopyable fields (sync.Once,
Ever since, people have been writing their own private Config.Clone
methods, or risking it and doing a language-level shallow copy and
copying the unexported sync variables.
Clean this up and export the Config.clone method as Config.Clone.
This matches the convention of Template.Clone from text/template and
html/template at least.
Updates #16228 (needs update in x/net/http2 before fixed)
Updates #16492 (not sure whether @agl wants to do more)
Run-TryBot: Brad Fitzpatrick <firstname.lastname@example.org>
TryBot-Result: Gobot Gobot <email@example.com>
Reviewed-by: Andrew Gerrand <firstname.lastname@example.org>
Also, the current DialWithDialer function copies the config in order to set an SNI value, but that has a complex interaction if the Config is being used for serving.
The net/http package also has its own variant of tls.Config.Clone which configs most but not all fields for the same or similar field race reason, because you can't clone a Config already in use for serving.
Maybe the right step is to make the exported Clone() skip the SessionTickets* variable? This would break session resumption on cloned Config, but that seems like less of a foot gun than having to discern what kind of copy we want.
Also, I think the title of this issue should be amended to mention that DialWithDialer is currently racy.