Skip to content

Conversation

PaulSD
Copy link
Contributor

@PaulSD PaulSD commented Apr 22, 2019

So apparently I missed an import line in #58 (See #60 🤦‍♂️). I've also since discovered problems with current versions of Go, which dropped support for golang.org/x/net/proxy. This PR fixes both of those issues.

@PaulSD
Copy link
Contributor Author

PaulSD commented Apr 24, 2019

I put GetProxyEnv() back (there is no harm in continuing to use it).

I replaced DialerFromEnvironment() with a no-op with a deprecation notice. Note that it is no longer necessary to set http.Transport.Dial from DialerFromEnvironment(), so code such as https://github.com/moby/moby/blob/b0e6eedcf4252d56e62fc3de6de5d01e75a3dc44/distribution/registry.go#L82 can simply be deleted.

@wtibbitts
Copy link

Is there an ETA on this fix?

@PaulSD
Copy link
Contributor Author

PaulSD commented Apr 29, 2019

Ping @thaJeztah

@thomasmodeneis
Copy link

up!

@thomasmodeneis
Copy link

Sorry, but this PR wont compile:
go-connections/sockets/proxy.go:5:2: imported and not used: "net/url"

@disafronov
Copy link

up!

@olljanat
Copy link
Contributor

@PaulSD what @thomasmodeneis says is valid. Can you plz remove that not used import so we can get this one merged?

MashiroC added a commit to MashiroC/go-connections that referenced this pull request May 16, 2019
I find there has a problem in docker#61(/sockets/sockets_windows)
/sockets/sockets_windows no longer need to declare `dialer`
(sorry my English is poor, Translate to google translate)
@olljanat
Copy link
Contributor

@thaJeztah @AkihiroSuda can we get this one merged with #62 ?
It is bit boring that code on master is broken...

Copy link
Collaborator

@AkihiroSuda AkihiroSuda left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please sign the commit with git commit -s and fix the compilation failure reported above

@AkihiroSuda
Copy link
Collaborator

#62 seems to lack the DCO as well

@PaulSD
Copy link
Contributor Author

PaulSD commented May 22, 2019

One moment, working on it...

@PaulSD
Copy link
Contributor Author

PaulSD commented May 22, 2019

Should be good now. Anything else I missed?

Copy link
Collaborator

@AkihiroSuda AkihiroSuda left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks

@wanyvic
Copy link

wanyvic commented May 27, 2019

work fine

@avii-wix
Copy link

Any ETA on merging this PR?

@AkihiroSuda
Copy link
Collaborator

ping @thaJeztah

@olljanat
Copy link
Contributor

Should be good now. Anything else I missed?

@PaulSD One minor thing. Can you modify comment line back on way that it starts with text DialerFromEnvironment other why it does not pass golint (noticed when I was creating #64)

You can test it locally with command:

golint -min_confidence 0.81 ./...

* Add missing import of "context" (Fixes
  docker#60)
* Drop configuration of the http.Transport.DialContext based on proxy
  settings (This was originally needed for SOCKS support, but has not
  been required since https://go-review.googlesource.com/c/go/+/35488/
  in Go 1.9, and is no longer supported as of
  https://go-review.googlesource.com/c/go/+/41031/ in Go 1.11)

Signed-off-by: Paul Donohue <[email protected]>
@PaulSD
Copy link
Contributor Author

PaulSD commented May 31, 2019

@olljanat Fixed, thanks!

@Innectic
Copy link

Innectic commented Jun 8, 2019

What is currently preventing this from being merged?

@AkihiroSuda AkihiroSuda merged commit 0f3f48b into docker:master Jun 8, 2019
@AkihiroSuda
Copy link
Collaborator

merging. I assume single LGTM is enough in this case

@AkihiroSuda
Copy link
Collaborator

AkihiroSuda commented Jun 8, 2019

cc @dnephin @thaJeztah @vdemeester

@thaJeztah
Copy link
Member

argh, sorry; yes, SGTM

if err != nil {
return err
}
tr.DialContext = dialer.DialContext
Copy link

@jamesmoessis jamesmoessis Jul 19, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems to have caused a problem for me because now the unix transport is used when I have specified an HTTP endpoint.

The dial context is used and for an http endpoint it tries to connect to a unix socket instead of a tcp socket.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not following you ...

The code you highlighted here was only used to configure the proxy on Go <1.9, and was removed because it is redundant and no longer necessary in Go >=1.9.

Removal of this code should not impact transport selection. Transport selection occurs a few lines earlier, and was not modified by this change: https://github.com/docker/go-connections/blob/master/sockets/sockets.go#L17

Maybe you have a proxy configured using a UNIX socket?

akerouanton added a commit to akerouanton/go-connections that referenced this pull request Oct 27, 2023
Since docker#61, there's no more DialContext defined in the default switch
case of ConfigureTransport. As a consequence, if ConfigureTransport was
already called with a npipe or unix proto (ie. Docker client does that
to initialize its HTTP client with the default DOCKER_HOST), the
DialContext function defined by these protocols will be used.

As the DialContext functions defined by unix and npipe protos totally
ignore DialContext's 2nd and 3rd argument (ie. network and addr) and
instead use the equivalent arguments passed to configureUnixTransport
and configureNpipeTransport when they were called, this results in
ConfigureTransport being totally ineffective.

In addition, DisableCompression is also reset to false.

Signed-off-by: Albin Kerouanton <[email protected]>
akerouanton added a commit to akerouanton/go-connections that referenced this pull request Oct 30, 2023
Since docker#61, there's no more DialContext defined in the default switch
case of ConfigureTransport. As a consequence, if ConfigureTransport was
already called with a npipe or unix proto (ie. Docker client does that
to initialize its HTTP client with the default DOCKER_HOST), the
DialContext function defined by these protocols will be used.

As the DialContext functions defined by unix and npipe protos totally
ignore DialContext's 2nd and 3rd argument (ie. network and addr) and
instead use the equivalent arguments passed to configureUnixTransport
and configureNpipeTransport when they were called, this results in
ConfigureTransport being totally ineffective.

In addition, DisableCompression is also reset to false.

Signed-off-by: Albin Kerouanton <[email protected]>
akerouanton added a commit to akerouanton/go-connections that referenced this pull request Oct 30, 2023
Since docker#61, there's no more DialContext defined in the default switch
case of ConfigureTransport. As a consequence, if ConfigureTransport was
already called with a npipe or unix proto (ie. Docker client does that
to initialize its HTTP client with the default DOCKER_HOST), the
DialContext function defined by these protocols will be used.

As the DialContext functions defined by unix and npipe protos totally
ignore DialContext's 2nd and 3rd argument (ie. network and addr) and
instead use the equivalent arguments passed to configureUnixTransport
and configureNpipeTransport when they were called, this results in
ConfigureTransport being totally ineffective.

In addition, DisableCompression is also reset to false.

Signed-off-by: Albin Kerouanton <[email protected]>
akerouanton added a commit to akerouanton/go-connections that referenced this pull request Oct 31, 2023
Since docker#61, there's no more DialContext defined in the default switch
case of ConfigureTransport. As a consequence, if ConfigureTransport was
already called with a npipe or unix proto (ie. Docker client does that
to initialize its HTTP client with the default DOCKER_HOST), the
DialContext function defined by these protocols will be used.

As the DialContext functions defined by unix and npipe protos totally
ignore DialContext's 2nd and 3rd argument (ie. network and addr) and
instead use the equivalent arguments passed to configureUnixTransport
and configureNpipeTransport when they were called, this results in
ConfigureTransport being totally ineffective.

Signed-off-by: Albin Kerouanton <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.