Some older npm clients ( specifically "classic" yarn ) incorrectly per npm spec send the following header when making NPM TGZ file requests:
The header value is only relevant for npm package metadata requests, NOT tgz requests.
Some known clients sending this header value on tgz requests are:
- yarn/1.22.10 npm/? node/v14.13.0 darwin x64
- yarn/1.22.10 npm/? node/v16.2.0 darwin x64
- yarn/1.22.4 npm/? node/v12.14.1 linux x64
- yarn/1.3.2 npm/? node/v10.2.0 darwin x64
- yarn/1.7.0 npm/? node/v12.13.0 linux x64
- only checks remote metadata if package can't be found in cached metadata
- handles new package situation
- avoids unnecessary metadata fetch if package is in the cache
- might still have unnecessary check if package is not in remote metadata
- but again expiry check should help in that regard
NEXUS-12821 is implemented to now store and serve two versions of a package metadata - the full metadata and abbreviated metadata.
This creates the following scenario when the Accept header value indicates abbreviated metadata for tgz request:
- npm tgz IS CACHED ALREADY in a proxy repo
- proxy remote is not reachable or "Allow proxy" repo setting is set to False or already cached package metadata is expired ( item max age or cache invalidated )
- when tgz request arrives for already cached tgz file for that package
- then repo 2 checks for the abbreviated metadata contains that version
- then since abbreviated metadata cannot be cached ( remote offline), repo 2 returns 404 not found for tgz request, failing builds
If the Accept header for a tgz request comes in with value that indicates abbreviated metadata, and package metadata needs to be checked before replying, don't return a 404 not found if the already cached full package metadata says the requested tgz version exists and the tgz is already cached locally.