Open felsokning opened 2 months ago
@ryuyu Could you please just repro this issue? If yes then please let's know.
I was able to repro this issue in dev. I haven't dug too deep into root causing yet, but I can confirm that it is reliably reproducible using the steps provided.
I was able to repro this issue in dev. I haven't dug too deep into root causing yet, but I can confirm that it is reliably reproducible using the steps provided.
Thank you. I'll follow up about prioritization.
Hey @felsokning, I have a workaround you can try, if you are interested. I am working on bringing https://github.com/NuGet/NuGetGallery/issues/8873 (an API to deprecate package) to a public preview. It's not there yet. But I can enable your user account for a private preview. It tried these extended-ASCII characters on the API and it appears to work just fine. I tried ö
in the package ID, the alternate ID, and the message.
I've found your NuGet.org username as the owner of the package IDs mentioned in your error report and enabled this user account for the deprecation API.
The pre-release API docs are here: https://github.com/NuGet/docs.microsoft.com-nuget/blob/jver-deprapi/docs/api/package-publish-resource.md#deprecate-or-undeprecate-a-package
You can use PowerShell, cURL, or whatever HTTP client you want to submit the request.
I have a .NET tool I wrote (not release by the team, my own proof-of-concept) that you can try if you don't want to script it yourself. https://www.nuget.org/packages/Knapcode.PackageLifeCycle#readme-body-tab
You need an API key with the "unlist" scope.
I'd love to hear if you are successful with the API or if you have any feedback/ideas/suggestions. Feel free to post your feedback publicly on the deprecation API issue (https://github.com/NuGet/NuGetGallery/issues/8873) or email me directly jver [at] microsoft [dot] com (whichever you prefer).
Impact
It's more difficult to complete my work
Describe the bug
It appears that URI Data Escape (or URL Escape) is happening for extended-ASCII characters (e.g.: ö -- in this case) in NuGet package names, when they are selected for being marked as deprecated on the website. This can be seen in the
id
field of the payload that's being sent to nuget.org (see screenshot).However, the
alternatePackageId
package name field is not escaped; which shows inconsistent behaviour - especially, if these fields are passed as URI parameters.As a result, this causes a 400 Bad Request error, which manifests as
An unknown error occurred when submitting the form.
on the website.Repro Steps
Steps to reproduce:
id
andalternatePackageId
fields, after receiving the 400 Bad Request.Expected Behavior
The request to deprecate all versions of the package should succeed.
Screenshots
Additional Context and logs
Below is the raw curl command generated by Edge to reproduce the issue: