fsprojects
Incompatible URLs used when downloading from NuGet.org
Hey there.
I'm a PM on the NuGet.org team and I wanted to reach out
NuGet.org is migrating towards a new multi-CDN infrastructure: NuGet/Announcements#60
Going forward, not all of our CDN providers will support case insensitive URLs. As a result, nuget.org's V3 API to download packages’ content will only support lowercased package ID and version values, as documented here: https://docs.microsoft.com/en-us/nuget/api/package-base-address-resource
For example:
❌ https://api.nuget.org/v3-flatcontainer/Newtonsoft.Json/13.0.1-Beta1/Newtonsoft.Json.13.0.1-Beta1.nupkg
✔ https://api.nuget.org/v3-flatcontainer/newtonsoft.json/13.0.1-beta1/newtonsoft.json.13.0.1-beta1.nupkg
Recently we received requests with uppercased package ID or versions from a client with user agent “Paket”. We recommend you update your project to use lowercased package ID and versions when downloading packages’ content using nuget.org’s V3 API.
Feel free to reach out to us at [email protected] or on GitHub at https://github.com/NuGet/NuGetGallery/issues if you have any questions or concerns.
Best regards,
NuGet Team
Thank you for this report!
I did a brief audit through the codebase and it looks like for v3 urls we are using lowercased package ids to get the metadata for a package from the 'registration base url' service, and then using the packageContent property from the catalog entries for the package we want to actually perform the download, and from last look those urls are all lowercased from the service's responses.
One thing that could be muddying the water is that the Paket user-agent doesn't have a version on it, so it's hard to tell if this is maybe a cluster of old paket users that haven't updated in a while...
I also ran our current tests and some manual tests with verbose logging for usages of the v3 endpoints and was able to manually verify that restore/update/download/etc operations all do use the correct casing, which I feel points to this old-versions consideration as well.
I think the most actionable thing is to add the Paket version to the user-agent (any restrictions or things you all would like to see in this header for analytics purposes @jcjiang?) and check back to see if any recent versions are exhibiting this incorrect behavior.
Paket now includes the version in the user-agent header, so it would be wonderful if over the next week/month(/longer?) you could flag if any paket clients with the version attached violated these urls @jcjiang.