go: cmd/go: should show error detail from module proxies

it seems there might be problems that have better errors if running with GOPROXY=direct, but then another class of problems that only occur when using the proxy and hence don’t occur when running with GOPROXY=direct.

Typically, proxy.golang.org serves the same error text as direct mode. Since the default in 1.13 is https://proxy.golang.org,direct, most users will end up with the direct error messages.

(We got a lot of reports of proxy-related confusion from users who had explicitly set GOPROXY on 1.12, but 1.12 does not support the fallback to direct.)

@bcmills, @jayconrod It looks like the related CL series is not going to be able to make the cut for 1.13? (Not sure of right CL(s), but maybe for example CL 189783).

I can understand if the full solution might be too risky, but I wonder if there is some simpler type of solution, or at least mitigation?

For example:

1. maybe cmd/go could emit some type of generic “consider re-running with GOPROXY=direct” message after a proxy returns a fatal error?

2. or maybe cmd/go could emit some type of “please visit https://proxy.golang.org/the/bad/uri for additional details”, where the uri corresponds to the one that returned the error status?

3. or maybe go get -v could emit the raw output, and the generic error could instead suggest go get -v?

4. or otherwise have cmd/go do something that helps point people towards some type of self-help step?

Here is a sample error message:

go: finding k8s.io/client-go v12.0.0+incompatible
go: k8s.io/client-go@v12.0.0+incompatible: unexpected status
(https://proxy.golang.org/k8s.io/client-go/@v/v12.0.0+incompatible.info): 410 Gone
go: error loading module requirements

Right now, I think that contains the error-causing uri? However, it doesn’t suggest visiting there, and that line doesn’t say “error”, and the key message is often nestled between other messages such that people don’t always focus on the most pertinent line or otherwise recognize it as the real error.

Also, is there something in the release notes currently on how to troubleshoot a proxy error?

I don’t quite have a handle on what classes of errors people are likely to see, but it seems there might be problems that have better errors if running with GOPROXY=direct, but then another class of problems that only occur when using the proxy and hence don’t occur when running with GOPROXY=direct.

CC @myitcv

@sirkon, I don’t think we even need application/json support for this.

What I have in mind is more like: if the content type is text/plain and the charset is either us-ascii or utf-8, show the first N lines up to a total of M characters.