[RRFC] Support sending custom request headers to an npm registry (`$MY_AUTH_HEADER: $VALUE`)

Motivation ("The Why")

I'd want to be able to set custom request headers in order to be able to use npm registries behind a proxy that requires a specific header key and value (Another use case might be custom caches/registries (for multiple programming languages) that require a header that isn't Authorization - this isn't a use case I've had, though)

• Proxies that have a mandatory HTTP custom header to authenticate are an alternative for hosting a private/internal registry, which can be used without needing a VPN

When a proxy is used to connect to a registry, it may have no way to accept an Authorization: HTTP header, especially if the applications it proxies use the Authorization for basic auth or oauth

The motivation of this is similar https://github.com/npm/npm/issues/18583

Example

• e.g. //my.private.registry.host.com/registry/path/:_customAuthHeader = My-Auth-Header: abcXYZ123:/== in a config file used by the npm cli would set req.headers['My-Auth-Header'] = abcXYZ123:/== (not familiar with whether this expects escaping or not, it should do what the _auth header does)

How

Current Behaviour

Only a few hardcoded headers are supported, as shown in the snippet: authorization:, and some npm-* headers

https://github.com/npm/npm-registry-fetch/blob/42d605cb00986c6775e6ec1732b114e065266ae9/lib/index.js#L211-L242

Desired Behaviour

Add support for adding custom headers through the .npmrc file

• e.g. //my.private.registry.host.com/registry/path/:_customAuthHeader = My-Auth-Header: abcXYZ123:/== in the .npmrc file used by the npm cli would set req.headers['My-Auth-Header'] = abcXYZ123:/== for requests to //my.private.registry.host.com/registry/path/ (not familiar with whether this expects escaping or not, it should do what the _auth header does)
• Optionally, this header could be repeatable, though I expect to only need one header set for the vast majority of use cases

Known http headers that have existing non-auth meanings or the npm headers that are already set may make sense to exclude (and emit a warning), with a case-insensitive string comparison (e.g. Content-Type, authorization, user-agent, etc.)

This could be limited to [a-zA-Z0-9_-] for the header key, and emit an error for other headers, to prevent sending invalid/ambiguous values, spaces, etc in the header key

• Key names found in Object.prototype such as __proto__ and toString could also be rejected just in case a custom server itself was buggy or an application using the npm-registry-client library other than npm was buggy
• The npm-* header prefix for unknown headers is something that I don't need - I'm fine with forbidding that entire prefix initially and leaving any RRFC for that to work to anyone who has a use case for those

I'd imagine this be similarly able to be scoped to a registry, similar to the always-auth/_authToken settings.

The key and value could be split on the first '=' and trimmed, then set the same way as other values in the getHeaders function

https://github.com/npm/npm-registry-fetch/blob/42d605cb00986c6775e6ec1732b114e065266ae9/lib/index.js#L211-L242

References

The motivation of this is similar https://github.com/npm/npm/issues/18583

I'd filed https://github.com/npm/npm-registry-fetch/issues/145 before discovering the rfcs repo (CONTRIBUTING.md in npm/npm-registry-fetch was a 404)

Start with getHeaders in lib/index.js at the linked lines, then trace how registry-scoped .npmrc settings reach it. Define the validation and precedence rules for custom headers, including conflicts with existing headers, before checking how requests are assembled. Done means a scoped configuration can reliably produce the requested custom header without accepting invalid or unsafe names.