New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
net/http: ProxyFromEnvironment does not support socks5h #24135
Comments
Seems reasonable. We need to clean up the x/net/socks* packages first, but then somebody can do this. /cc @mikioh |
Change https://golang.org/cl/156518 mentions this issue: |
As a git user, which has recently started using git-lfs, which in turn is written in go, I've stumbled across the same issue. |
Golang does not support the 'socks5h://' schema for http[s]_proxy env variable: https://github.com/golang/go/blob/9123221ccf3c80c741ead5b6f2e960573b1676b9/src/vendor/golang.org/x/net/http/httpproxy/proxy.go#L152-L159, while libcurl supports it: https://github.com/curl/curl/blob/ae98b85020094fb04eee7e7b4ec4eb1a38a98b98/docs/libcurl/opts/CURLOPT_PROXY.3#L48-L59. So, if a 'https_proxy=socks5h://127.0.0.1:1080' env has been set in the make.conf to make curl (assuming curl is the current download command) to download all packages through the proxy, go-module_live_vendor will fail. The only difference between these two schemas is, 'socks5h' will solve the hostname via the proxy while 'socks5' will not. I think it's ok to fallback 'socks5h' to 'socks5' for `go vendor` command and warn user, until golang supports it. related to issue: golang/go#24135
Golang does not support the 'socks5h://' schema for http[s]_proxy env variable: https://github.com/golang/go/blob/9123221ccf3c80c741ead5b6f2e960573b1676b9/src/vendor/golang.org/x/net/http/httpproxy/proxy.go#L152-L159, while libcurl supports it: https://github.com/curl/curl/blob/ae98b85020094fb04eee7e7b4ec4eb1a38a98b98/docs/libcurl/opts/CURLOPT_PROXY.3#L48-L59. So, if a 'https_proxy=socks5h://127.0.0.1:1080' env has been set in the make.conf to make curl (assuming curl is the current download command) to download all packages through the proxy, go-module_live_vendor will fail. The only difference between these two schemas is, 'socks5h' will solve the hostname via the proxy while 'socks5' will not. I think it's ok to fallback 'socks5h' to 'socks5' for `go vendor` command and warn user, until golang supports it. related to issue: golang/go#24135 Signed-off-by: Ryan Qian <i@bitbili.net>
currently only http/https/socks5 scheme are allowed. However, any scheme could be possible if user provides their own implementation. Specifically, the widely used `socks5h://localhost` is parsed as Scheme="http" Host="socks5h:", which does not make sense because host name cannot contain ":". This patch allows any scheme to appear in the proxy config. And only fallback to http scheme if parsed scheme or host is empty. `url.Parse` result of fallback cases: localhost => Scheme="localhost" localhost:1234 => Scheme="localhost" Opaque="1234" example.com => Path="example.com" Updates golang/go#24135
Change https://go.dev/cl/525257 mentions this issue: |
Could someone help me review this cl https://go.dev/cl/525257 please? |
currently only http/https/socks5 scheme are allowed. However, any scheme could be possible if user provides their own implementation. Specifically, the widely used "socks5h://localhost" is parsed as Scheme="http" Host="socks5h:", which does not make sense because host name cannot contain ":". This patch allows any scheme to appear in the proxy config. And only fallback to http scheme if parsed scheme or host is empty. url.Parse() result of fallback cases: localhost => Scheme="localhost" localhost:1234 => Scheme="localhost" Opaque="1234" example.com => Path="example.com" Updates golang/go#24135 Change-Id: Ia2c041e37e2ac61be16220fd41d6cb6fabeeca3d Reviewed-on: https://go-review.googlesource.com/c/net/+/525257 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Damien Neil <dneil@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Damien Neil <dneil@google.com>
Extend the net/http Transport to recognize the 'socks5h' schema as an alias for 'socks5'. Traditionally, the 'socks5h' schema indicates that the hostname should be resolved by the proxy server, which is behavior already implemented in Go for 'socks5'. The update requires upgrading the golang.org/x/net dependency to support any proxy schema, including 'socks5h', specified through environment variables. Fixes golang#24135
Change https://go.dev/cl/569977 mentions this issue: |
Change https://go.dev/cl/570156 mentions this issue: |
Commands run (in both src and src/cmd): go get golang.org/x/net@master go mod tidy go mod vendor For #24135 Change-Id: I88084d174c15a65350be1b43e27de619dc6d4dd6 Reviewed-on: https://go-review.googlesource.com/c/go/+/570156 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: 胡玮文 <huww98@outlook.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env
)?What did you do?
What did you expect to see?
What did you see instead?
go get
does not understandsocks5h
inHTTPS_PROXY
, even though it understandssocks5
.For example, to test using the tor proxy:
Other tools that understand
HTTPS_PROXY
also understandsocks5h
(resolve hostname through the proxy, not locally). curl and yum, for example.Related to issue #18508.
The text was updated successfully, but these errors were encountered: