Npm scoped packages - String is not a valid semantic version error

[Guest]

We're still researching it; there were some changes in 4.6 to the HTTP Handling, but it seems to have some issues w/ some IIS configurations (or perhaps, libraries used by IIS? patch versions of .net? not sure yet)...

The underlying problem is the %2f as part of the path. This is simply not a common scenario, and is almost always accidental, which is why the underlying libraries (proxy servers sometimes, etc) automatically convert it to a "/" when passing it to the next thing in the pipeline.

[Guest]

Same problem here. We can't install any scoped package. Also when we open an deployed own scoped package, an unhandled error occurred:

Invalid npm package id.
with the following stacktrace:
[FormatException: Invalid npm package id.]
Inedo.ProGet.WebApplication.UnifiedFeedBrowsing.Feeds.NpmFeedDataFactory.ParsePackageIdentifier(String urlPackageVersionIdentifier) +518
Inedo.ProGet.WebApplication.Pages.Packages.PackageVersionPage.CreateChildControls() +173
Inedo.ProGet.WebApplication.Pages.<InitializeAsync>d__2.MoveNext() +281
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) +144
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) +84
Inedo.ProGet.WebApplication.Pages.Packages.<InitializeAsync>d__18.MoveNext() +950
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) +144
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) +84
Inedo.Web.PageFree.<ProcessRequestAsync>d__48.MoveNext() +380
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) +144
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) +84
System.Web.TaskAsyncHelper.EndTask(IAsyncResult ar) +98
System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +606
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +288

It's very urgently needed to get this running;)

[Guest]

Unfortunately, at this point, we're unable to reproduce this at all, under any configurations of Windows. Upon installing a trace on the incoming requests to ProGet, the underlying problem is that the request being made to ProGet is incorrect, it has a / in the url instead of %2f.

So, we believe a proxy server or intermediate network appliance is replacing %2f with /. We have seen some reverse proxies do this already. It is highly unusual for a path to contain a %2f, so this is probably why such a problem/bug in the intermediate hardware would go unnoticed.

[Guest]

Hi Alana,

When you say "the request being made to ProGet is incorrect, it has a / in the url instead of %2f", we have tried making direct requests to ProGet using Postman with both escaped and non-escaped paths and we still get the same error, i.e:

http://cap-pkg.coretexa.local:8080/npm/C3-NPM/@angular%2Fcore
http://cap-pkg.coretexa.local:8080/npm/C3-NPM/@angular/core

both produce the "String is not a valid semantic version" error.

We don't get the error when we try the same thing using a non-scoped npm package path, i.e.

http://cap-pkg.coretexa.local:8080/npm/C3-NPM/moment

Also, when you say "it is highly unusual for a path to contain a %2f", every npm scoped package will contain this as that is the format for a scoped package.
https://docs.npmjs.com/getting-started/scoped-packages

Scoped npm packages are becoming increasingly more common so it would be great to have a solution to this.

Regards,
David

[Guest]

Hi,

our case is fixed by adding the following configuration to the Web.config

<add key="aspnet:UseLegacyRequestUrlGeneration" value="true" />
Problem was the decoded @ in the url from the schöpfe package name.

[Guest]

Thanks very much Jean-Pierre,

That solved my problem.

Regards,
David

[Guest]

Thanks very much Jean-Pierre, this solved also my case.

[Guest]

Wow, great find... so, we will update the web.config that we ship with to contain this!

[Guest]

Your Welcome;)
We decompiled the code and debugged it to solve the problem. It took us the whole day:(
=> Alana, perhaps you could think about some logging, this would help us a lot;)

[Guest]

I found this thread after experiencing a similar issue. I was seeing the "string is not a valid semantic version error" from Proget when npm would try to install scoped packages, but only when the npm install was automatically triggered inside Visual Studio by a change to the package.json. We already had the latest version of Proget with the change to the web.config and installs worked fine when running from command line.

Problem turned out to be the fact that Visual Studio 2015 had installed it's own copy of the npm.cmd as an external web tool. This was an older version than the one I had installed globally, but the order of external web tool locations in Visual Studio had the path to the older version listed before my system path. Making system path take precedence solved the issue.

Just thought I'd post this here in case anyone else with a similar issue stumbles across this thread like I did.