client: deterministically resolve http scheme

The docker client has historically used Transport.TLSClientConfig to set
the scheme for the API client. A recent moved the resolution to use the
http.Transport directly, rather than save the TLSClientConfig state on a
client struct. This caused issues when mutliple calls made with a single
client would have this field set in the http package on pre-1.7
installations. This fix detects the presence of the TLSClientConfig once
and sets the scheme accordingly.

We still don't know why this issue doesn't happen with Go 1.7 but it
must be more deterministic in the newer version.

Signed-off-by: Stephen J Day <stephen.day@docker.com>

1 files changed, 0 insertions, 17 deletions

diff --git a/client/transport.go b/client/transport.go
index 771d76f06b..f04e601649 100644
--- a/client/transport.go
+++ b/client/transport.go
@@ -26,20 +26,3 @@ func resolveTLSConfig(transport http.RoundTripper) *tls.Config {
 		return nil
 	}
 }
-
-// resolveScheme detects a tls config on the transport and returns the
-// appropriate http scheme.
-//
-// TODO(stevvooe): This isn't really the right way to write clients in Go.
-// `NewClient` should probably only take an `*http.Client` and work from there.
-// Unfortunately, the model of having a host-ish/url-thingy as the connection
-// string has us confusing protocol and transport layers. We continue doing
-// this to avoid breaking existing clients but this should be addressed.
-func resolveScheme(transport http.RoundTripper) string {
-	c := resolveTLSConfig(transport)
-	if c != nil {
-		return "https"
-	}
-
-	return "http"
-}