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

For unpublished versions, have registry return 410 Gone and clients re-resolve semantic version #24

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

markstos
Copy link

@markstos markstos commented Dec 6, 2018

Unpublished packages currently cause pain for NPM users. A recommended approach ends up being to delete your lock file and re-generate it, which can cause a huge amount of dependencies to change when only one was needed.

Unpublished packages currently return the HTTP status code "404 Not Found". This code is designed for resources that might exist again in the future. In the NPM ecosystem, version numbers are wisely
immutable. A better HTTP status code to return for an unpublished package is "410 Gone", designed for resources that will never come back.

When npm encounters a 410 Gone resource, it could try to resolve the related semantic version again, possibly selecting a newer version, fixing the issue for the single dependency without requiring regenerating the entire lock file.

To clarify, this proposal is only for tarball URLs for specific versions. If you do npm unpublish -f foo, then the request to https://registry.npmjs.org/foo should return a 404, not a 410, because someone else can publish new versions of foo (though, importantly, then cannot reuse old version numbers, and thus cannot take over the same tarball URLS - those are gone for good.)

@zkat
Copy link
Contributor

zkat commented Dec 20, 2018

I'm gonna /cc @bonkydog on this one, since it relates to their team. But my completely nonofficial position on this is that I like it, pending Brian's team's approval 👍

@zkat
Copy link
Contributor

zkat commented Jan 30, 2019

Brief update: We've moved this internally to appropriate channels and we'll be doing an internal review + prioritization of this feature. No timeline until that's done.

@darcyclarke darcyclarke added Agenda will be discussed at the Open RFC call Enhancement new feature or improvement Needs Discussion is pending a discussion Registry labels Oct 30, 2019
@darcyclarke darcyclarke removed Needs Discussion is pending a discussion Agenda will be discussed at the Open RFC call labels Nov 27, 2019
@mikemimik
Copy link

There is some internal work happening on the registry around unpublishing packages. To that effect, there is some changes happening around the status codes as well. There is an action item from #70 that will follow up with that feature team to make sure this gets added or at least addressed.

@Ethan-Arrowood
Copy link

Ethan-Arrowood commented Dec 13, 2019

In a similar aspect - if a package is deprecated in place of another package could we use a redirect code (301 or 308)? It could definitely be a security issue if we allow users to redirect their packages, so maybe instead it errors but also provides the recommended alternative library? (should I open a secondary RFC for this or is it relevant enough to this one?)

@markstos
Copy link
Author

I would issue a HTTP Redirect response sparingly-- only in a case where a module was found to have a security flaw and there's a known replacement which works exactly the same but lacks the security flaw.

@isaacs
Copy link
Contributor

isaacs commented Jan 31, 2020

Just to clarify the discussion between @seldo and me regarding url reuse, that was about unpublishing all versions of a package. Ie, if you do npm unpublish -f foo, then the request to https://registry.npmjs.org/foo should return a 404, not a 410, because someone else can publish new versions of foo (though, importantly, then cannot reuse old version numbers, and thus cannot take over the same tarball urls - those are gone for good.)

Responding with a 410 response code to tarball urls for deleted package versions is entirely appropriate, and I don't see any reason to oppose the fallback logic described in this RFC, but may have some feedback when we start trying to implement it.

The first step, of course, is to see if we can get the registry to respond with a 410 to deleted tarball requests,

@markstos
Copy link
Author

Good clarification @isaacs. I've updated the RFC to clarify that the scope is restricted to tarball URLs and include your note that completely removing a package is a different case.

@markstos markstos changed the title Unpublished modules should return 410 Gone For unpublished versions, have registry return 410 Gone and clients re-resolve semantic version Jan 31, 2020
@settings settings bot removed the Registry label Sep 21, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement new feature or improvement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants