Skip to content
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

cmd/go/internal/modfetch: re-evaluate the undocumented proxy behavior in proxyRepo.latest() #32789

hyangah opened this issue Jun 26, 2019 · 1 comment


None yet
4 participants
Copy link

commented Jun 26, 2019

Forked from the discussion during the review of

  1. undocumented /@v/list format

proxyRepo.latest() assumes /@v/list could return a list of version, commit timestamp pairs. This is not documented in the proxy protocol doc, and I am not sure if there is any proxy that's following this format. Please reject the undocumented format or document it.

One of the benefit of preserving this feature is, when this proxyRepo.latest() is invoked, the commit timestamp info here is more reliable than the timestamp parsed from the pseudo-version like version string and helps avoiding an extra proxyRepo.Stat() call. On the other hand, the code path can be completely eliminated if proxies implement the /@latest endpoint, which is also not documented.

  1. whether to include pseudo-versions or not in /@v/list

The proxyRepo.latest() itself is also relying on part of undocumented behavior of /@v/list, which is supposed to include pseudo-versions. Before (pre-1.13), we assumed it's not a good idea to include the pseudo versions in the /@v/list output and planned to include that in the proxy protocol spec.

// List returns a list of tagged versions of the module identified by path.
// The versions should all be canonical semantic versions
// and formatted in a text listing, one per line.
// Pseudo-versions derived from untagged commits should be omitted.
// The go command exposes this list in 'go list -m -versions' output
// and also uses it to resolve wildcards like 'go get m@v1.2'.`

If the spec draft is valid, the proxyRepo.latest() implementation doesn't do anything but an extra network round trip for the proxies that follow the spec. If the go command can handle the list output including pseudo-versions, we may want to revisit the decision.

So, I propose either

  1. tighten the spec to require the /@latest endpoint. Then, remove the code that leads to the proxyRepo.latest(), or
  2. relax the /@v/list format and allow pseudo versions in its output, and document it.

Option 2) implies more code to maintain on cmd/go side. Option 1) implies breakage of proxies that doesn't implement the /@latest endpoint.

p.s. having the go command's proxyRepo.Versions ensure not to return pseudo versions is a good fix though.


This comment was marked as resolved.

Copy link

commented Jun 26, 2019

s/also not implemented/also not documented/?

@bcmills bcmills added this to the Go1.14 milestone Jun 26, 2019

@andybons andybons added the NeedsFix label Jun 28, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.