Make the go CLI respect "redirect" HTML metadata tags

[arschles]

When GOPROXY is set, the go CLI won't do a ?go-get=1 request and so won't get the HTML redirect metadata. We need it to do that so that the registry works out of the box. Ideally, I'd like the go CLI to have another setting (or hard-coded) a URL to the registry that it hits with ?go-get=1, so that we can serve the HTML

This is a continuation of #241

[arschles]

cc/ @bketelsen - we have discussed embedding or adding configuration to the go CLI to respect "built in" (or configurable) URLs for public registries

[marwan-at-work]

@arschles why do we need this? What scenario is not currently working?

[arschles]

@marwan-at-work right now if you GOPROXY=my.proxy go get module@v1, the @v/list endpoint is hit, so we can't send the meta tag redirect to the CLI (i.e. what gopkg.in does to redirect to a github tag).

So that means that we can't send the go tool to a CDN for the entire download protocol (which is basically a must for public proxy usage), unless a user does a go get my.proxy.com/github.com/my/module@version. That should totally work, but the UX could be better. I'd ideally like go get module@version to default to the global proxy (when that is up and running and stable) unless the user indicates otherwise.

Hopefully I've made sense here!

[marwan-at-work]

@arschles if GOPROXY=my.proxy go get module@v1 is run our @v/list endpoint handler will internally call go list -m -versions -json module@v1 and it should properly do the return for us.

Here's an example from my local machine

gopkg.in vanity

go list -m -versions -json gopkg.in/yaml.v2@latest
go: finding gopkg.in/yaml.v2 v2.2.1
{
	"Path": "gopkg.in/yaml.v2",
	"Version": "v2.2.1",
	"Versions": [
		"v2.0.0",
		"v2.1.0",
		"v2.1.1",
		"v2.2.0",
		"v2.2.1"
	],
	"Time": "2018-03-28T19:50:20Z"
}

regular vanity

go list -m -versions -json golang.org/x/build@latest
go: finding golang.org/x/build latest
{
	"Path": "golang.org/x/build",
	"Version": "v0.0.0-20180803185637-c1b72a71f268",
	"Time": "2018-08-03T18:56:37Z"
}

[arschles]

@marwan-at-work we've talked about redirecting in other ways than the meta tag (#474). we could use the 301 described in #474 instead of this approach if we want. do you think it's appropriate to close this?

[marwan-at-work]

yes, closing.