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

x/website: https://golang.org/dl/?mode=json&include=all to https://golang.org/dl/releases.json #45800

Open
gibfahn opened this issue Apr 27, 2021 · 4 comments

Comments

@gibfahn
Copy link

@gibfahn gibfahn commented Apr 27, 2021

The releases json file is used by a bunch of tools like rules_go to get a list of go releases.

The current URL works fine for many cases, but trips up mirror sites, for example if you use Artifactory to cache the URL it won't refresh the cache as it doesn't understand the URL format.

Given the comments in the original issue (#23746 (comment)):

@bradfitz - sounds great, I'll get around to this during the weekend. Any thoughts on the releases.json URL? Could probably just be /releases

I don't care much. We use ?mode=json for build.golang.org/?mode=json though.

Would it be acceptable to provide this at an alternate URL like the originally proposed https://golang.org/dl/releases.json? Probably makes sense to mirror both the include=all and the normal releases (see #29380).

This would also make things like curl -O work more nicely (as the downloaded name would be releases-all.json rather than ?mode=json&include=all.

Proposal:

Existing Mirror
https://golang.org/dl/?mode=json https://golang.org/dl/releases.json
https://golang.org/dl/?mode=json&include=all https://golang.org/dl/releases-all.json
@seankhliao seankhliao changed the title Mirror https://golang.org/dl/?mode=json&include=all to https://golang.org/dl/releases.json x/website: https://golang.org/dl/?mode=json&include=all to https://golang.org/dl/releases.json Apr 27, 2021
@gopherbot gopherbot added this to the Unreleased milestone Apr 27, 2021
@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented Apr 27, 2021

@jayconrod
Copy link
Contributor

@jayconrod jayconrod commented May 3, 2021

Seems reasonable to mirror the URL. I think that just means routing the request to the same code.

This does sound like a bug in Artifactory though. Query strings are valid parts of URLs. They shouldn't be ignored for caching.

@dmitshur
Copy link
Contributor

@dmitshur dmitshur commented May 3, 2021

The proposed scheme has some convenience improvements in specific cases, but I think the bar for introducing and perpetually maintaining a mirror of an API needs to be higher than minor convenience improvements.

but trips up mirror sites

If this can be fixed in those mirror sites (as Jay suggested), that seems like a better location for the fix.

As one example of API designs with similar properties, GitHub API v3 uses JSON responses also without a ".json" suffix in the URL, and accepts query parameters, such as https://api.github.com/repos/golang/go/events?per_page=3.

@gibfahn
Copy link
Author

@gibfahn gibfahn commented May 5, 2021

If this can be fixed in those mirror sites (as Jay suggested), that seems like a better location for the fix.

I don't disagree, although in practice I'm certain it's going to be a much longer process to get Artifactory (and likely other software) to change how they do caching than it would be to use a different URL for this server. Plan is to attempt both 😁 .

As one example of API designs with similar properties, GitHub API v3 uses JSON responses also without a ".json" suffix in the URL, and accepts query parameters, such as api.github.com/repos/golang/go/events?per_page=3.

I guess it depends whether one treats this as a file that is occasionally updated, or an API call (or both). Artifactory treats it as the former (probably because caching API calls in general doesn't make so much sense). I was thinking of this like the Node.js equivalent (https://nodejs.org/dist/index.json).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants