Cannot install package from scope registry

[tyler-johnson]

I'm opening this issue because:

• npm is crashing.
• npm is producing an incorrect install.
• npm is doing something I don't understand.
• Other (see below for feature requests):

What's going wrong?

I have my NPM configured to use a different registry for my company's scope. In my .npmrc is this line:

@beneaththeink:registry=https://license.system.pagedip.com/npm

NPM 4 installs using this registry just fine, however NPM 5 crashes when attempting to retrieve a tarball. It seems like the NPM client is still attempting to get tarballs directly from the NPM registry, instead of my custom registry.

How can the CLI team reproduce the problem?

Here is the NPM debug log of my attempted install: https://gist.github.com/tyler-johnson/9717fb01324e811987b51e53ffc8d769

I imagine this can be reproduced by installing from any custom scope registry.

supporting information:

• npm -v prints: 5.0.1
• node -v prints: 7.10.0
• npm config get registry prints: https://registry.npmjs.org/
• although npm config get @beneaththeink:registry prints: https://license.system.pagedip.com/npm
• Windows, OS X/macOS, or Linux?: macOS 10.12.5
• Network issues:
  • Geographic location where npm was run: Colorado, USA
  • I use a proxy to connect to the npm registry. (Edit: personally don't use a proxy, only checked this as my custom registry proxies to the real NPM registry)
  • I use a proxy to connect to the web.
  • I use a proxy when downloading Git repos.
  • I access the npm registry via a VPN
  • I don't use a proxy, but have limited or unreliable internet access.
• Container:
  • I develop using Vagrant on Windows.
  • I develop using Vagrant on OS X or Linux.
  • I develop / deploy using Docker.
  • I deploy to a PaaS (Triton, Heroku).

[tyler-johnson]

This turned out as a result of several compounding issues:

• NPM 5 does not set the Accept header on the install request, where NPM 4 did.
• The NPM registry (and CouchDB I believe) does not set the Content-Type header to application/json unless the Accept header is set.
• The proxy was looking for Content-Type as application/json on the response to parse and manipulate the dist.tarball value.

This has been fixed on the proxy side by forcing an Accept header to be set so this is closed for my purposes.