Nuget badges inaccessible

[304NotModified]

(Comment hijacked to summarize the advancement.)

https://github.com/badges/shields/blob/5e4c71181372b5ec86b844aded99acb5f0270b28/server.js#L3163

NuGet returns a different content type, which is probably why shields.io breaks on the XML/Atom response received from NuGet.

Using the v3 API:

• Append the package identifier + index.json, for example: https://api.nuget.org/v3/flatcontainer/{packageid-lowercase}/index.json. The JSON has all versions of the package and can tell you in one go what the latest version is. eg, https://api.nuget.org/v3/flatcontainer/microsoft.aspnet.mvc/index.json
• Get the latest version: (latest = last item in the list, latest stable is last one in the list that does not have a - in the version number)

There is no download information in v3, we'd have to keep the old system which still works for Chocolatey.

Chocolatey doesn't seem to use the v3: https://api.chocolatey.org/v3/flatcontainer/scriptcs/index.json, so we can't use it even for versions.

We cannot find the v3 endpoint for myget: neither https://www.myget.org/F/yolodev/api/v3/flatcontainer/fsharpsupport/index.json nor https://api.myget.org/F/yolodev/v3/flatcontainer/fsharpsupport/index.json work.

---

(Original comment here.)

The NuGet badges are inaccessible for days. Is this a rate limit? Is there something I can do? Is this for every visitor? Can you cache more at your side?

Current what I see:

One of the links:

• https://img.shields.io/nuget/v/NLog.svg
• https://www.nuget.org/packages/NLog

We see it also on shield.io:

We have arround 5K views/day

[MathewSachin]

I also experience the same issue on my repository with not that many views.

[odinserj]

I have the same with Hangfire project.

[t1st3]

seems it is fixed (2016/02/23 11PM LMT)

[odinserj]

Confirming, fixed :tada:

[304NotModified]

Down again

[304NotModified]

we moved partly to https://badge.fury.io/for/nu, which do work (but has less features)

[dustinmoris]

Shields NuGet badges stopped working for me as well so I added support for NuGet badges to buildstats.info.

[SimonCropp]

any update on this?

[maartenba]

Seems this is the culprit: https://github.com/badges/shields/blob/5e4c71181372b5ec86b844aded99acb5f0270b28/server.js#L3163

NuGet returns a different content type, which is probably why shields.io breaks on the XML/Atom response received from NuGet.

Alternatively, you may want to use the V3 API for shields as it is much, much faster. The goal is to pick the latest version, right?

• First, grab the RegistrationBaseAddress entry from https://api.nuget.org/v3/index.json (this does not change often but it's best to grab it every once in a while)
• Then append the package identifier + index.json, for example: https://api.nuget.org/v3/flatcontainer/{packageid-lowercase}/index.json. The JSON has all versions of the package and can tell you in one go what the latest version is.

[304NotModified]

@maartenba thx for the tech info!

@espadrine can you help us with this?

[danbarua]

The MyGet badge is broken too.

[304NotModified]

The MyGet badge is broken too.

Good luck. We have issues with the NuGet badges for more then 30 days, without any response of shields.io team.

[dustinmoris]

@danbarua I have added a MyGet badge to buildstats.info. Please have a look if it suits you...

[SimonCropp]

i moved to buildstats

[danbarua]

@dustinmoris Sweet, thanks!

[kzu]

Confirmed to still be broken :(

[Yortw]

Still broken for me too.

[atifaziz]

Likewise

[espadrine]

We have issues with the NuGet badges for more then 30 days, without any response of shields.io team.

Sorry. PRs get priority treatment, which unfortunately can only go as fast as I can review them.

NuGet returns a different content type, which is probably why shields.io breaks on the XML/Atom response received from NuGet.

Yes, I receive XML which I parse as JSON. @Alxandr do you know if there is an easy fix?

Chocolatey still works fine with the same code, though.

First, grab the RegistrationBaseAddress entry from https://api.nuget.org/v3/index.json (this does not change often but it's best to grab it every once in a while)

That could be done with regularUpdate(). I cannot find RegistrationBaseAddress in it though.

[AArnott]

@espadrine: @maartenba's prescribed fix looks pretty simple, and his URLs result in JSON responses so it would avoid you having to parse XML.

[espadrine]

@AArnott I am very much open to PRs on this. I know very little about NuGet, let alone its API. Given the range of what we support, it feels nontrivial for me to replace it without breaking Chocolatey, even if the described fix was clear. But as I said, I cannot find RegistrationBaseAddress in https://api.nuget.org/v3/index.json, and https://api.nuget.org/v3/flatcontainer/microsoft.aspnet.mvc/index.json yields limited information.

It is unclear to me how to ask for the latest version (with or without including prerelease ones), and doing it manually will cause pain (should we use semver? what if there is a non-semver version in the list?). I don't know where the download information is stored.

[maartenba]

Oops, need to be RegistrationsBaseUrl. ANd all URLs sould be lowercase at all times.

[AArnott]

@espadrine: for what it's worth, both I and @vbfox tried to prepare a PR for this change, but we couldn't get your project's dependencies installed locally to prepare the fix. We both have Windows machines, and @vbfox even tried setting up a Linux box.

[espadrine]

@maartenba thanks. What is the purpose of the registration URL? Do you know if there is a way to ask for the latest version, as we had before when using filters? Also, where is the download information?

Is there a good link to the most exhaustive piece of documentation on the v3 API?

@AArnott A change I merged yesterday should make local testing much easier, as the project no longer relies on Cairo.

[maartenba]

@espadrine The registration URL has all versions of the package. There is also PackageBaseAddress/3.0.0 which has just the list of versions, for example https://api.nuget.org/v3/flatcontainer/microsoft.aspnet.mvc/index.json (latest = last item in the list, latest stable is last one in the list that does not have a - in the version number)

Regarding downloads, there is no API for that currently.

[espadrine]

Unfortunately, chocolatey doesn't seem to use the v3: https://api.chocolatey.org/v3/flatcontainer/scriptcs/index.json

The same goes for myget: neither https://www.myget.org/F/yolodev/api/v3/flatcontainer/fsharpsupport/index.json nor https://api.myget.org/F/yolodev/v3/flatcontainer/fsharpsupport/index.json

[kzu]

shouldn't all those be different paths though? Why would chocolatey or myget limit what API you use for nuget.org? Aren't (or shouldn't) they different badges altogether?

[espadrine]

They have different domains, but the same code is running on each of those domains, so we could perform the same requests.

[Alxandr]

Myget supports v3. Chocolatey I have no idea.

[espadrine]

@Alexandr do you know what URL I should try for MyGet?

[Alxandr]

The entrypoint of a feed is here https://www.myget.org/F/dotnet/api/v3/index.json

If you just go to the nuget gallery and pick a random feed (like I just did) it'll tell you.

[espadrine]

The entrypoint of a feed is here https://www.myget.org/F/dotnet/api/v3/index.json

I can see https://dotnet.myget.org/F/dotnet-corert/api/v3/flatcontainer/ in there. I'm not sure how to get fsharpsupport, for instance: https://dotnet.myget.org/F/dotnet-corert/api/v3/flatcontainer/fsharpsupport/index.json

[Alxandr]

The dotnet feed and the yolodev feed are not the same.

https://dotnet.myget.org/F/dotnet-corert/api/v3/flatcontainer/Microsoft.DotNet.AppDep/index.json

[espadrine]

The yolodev feed still exists, though, right? https://www.myget.org/F/yolodev/api/v3/flatcontainer/FSharpSupport/index.json yields nothing, and yet https://yolodev.myget.org/F/yolodev/api/v3/index.json yields https://www.myget.org/F/yolodev/api/v3/flatcontainer/.

[Alxandr]

Yes, but that package no longer does :)

https://www.myget.org/F/yolodev/api/v3/flatcontainer/YoloDev.Dnx.FSharp/index.json

[espadrine]

Unfortunately, the download information is lost in translation for both nuget and myget.

[304NotModified]

Thanks for the fix!

[kzu]

Awesome! Thanks!

On Tue, Mar 15, 2016 at 3:01 PM Julian Verdurmen notifications@github.com wrote:

Thanks for the fix!

— You are receiving this because you commented.

Reply to this email directly or view it on GitHub https://github.com/badges/shields/issues/655#issuecomment-196950509

[atifaziz]

Cheers! :clap: