proposal: x/net/internal/socks, socks_bundle.go in net/http: new package

[mikioh]

The commit f6698cf introduced the golang.org/x/net/proxy package into the standard library. At the same time, it also carried #19354. As far as I can see, the net/http package only requires a SOCKS client implementation, not a generic forward proxy client implementation. Moreover, the existing/introduced proxy package has several issues that will cause future troubleshooting difficulties like #11682.

I'd like to propose to do the following during Go 1.9 development cycle:

1. factor out SOCKS client implementation code from x/net/proxy and make it a new package
2. fix issues like x/net/proxy: does not support dialing with a given Context #19354 and x/net/proxy: SOCKS5 errors are all *errors.errorString #11682 in the new package
3. replace vendored x/net/proxy with the new package

[gopherbot]

CL https://golang.org/cl/38278 mentions this issue.

[bradfitz]

Do you propose breaking people currently using https://godoc.org/golang.org/x/net/proxy#SOCKS5 ?

[rsc]

Two issues:

1. Make it easier to pull socks bug fixes into stdlib. That would be possible with no API changes by creating x/net/proxy/internal/socks and using it from x/net/proxy.

2. Proxy doesn't have context support, and adding it could break existing users.

I think we should do (1) but not expose new socks details to users unless and until they need them.

[rsc]

And (2) can be a different issues.

[mikioh]

Do you propose breaking people currently using ...

I don't understand your question. I didn't say anything about the package x/net/proxy API, also CL 38278 doesn't break the existing applications. What's the purpose of this question?

creating x/net/proxy/internal/socks

I'm fine with this.

[mikioh]

Are there other opinions on preferring x/net/internal/socks than x/net/socks pacakge? I'm really fine either way because what I want to see is a) no troublesome for the use of http over socks, b) a concrete socks client implementation package for my use case.

[bradfitz]

I'm okay with socks (not internal) if it can start minimal, and if it has package docs saying that it has no compatibility promises.

[rsc]

Let's just do internal please, until someone actually needs socks exposed. The new package in CL 38278 has an enormous amount of API for a trivial thing. I'd really like to keep the trivial thing trivial.

[mikioh]

Sorry, what you are saying "trivial stuff" is important for my use case; especially accepting bind command and external authentication mechanisms, and notifying a server bound address on a proxy connection because the value of SOCKS to me is that it glues transport protocols together. I'd want to use x/net/internal/socks by vendoring, but if you dislike that approach, I'm happy to drop this proposal and CL 38278.

[bradfitz]

So you're saying it can't be minimal.

Internal it is.

[bradfitz]

(But I will still say no to unnecessary stuff like "bind" for now.)

[rsc]

It sounds like there are details to work out in the CL but we agree that x/net/socks should exist.