Details
-
Type:
Bug
-
Status: Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 3.35.0, 3.37.3
-
Fix Version/s: None
-
Component/s: NPM
-
Labels:
-
Epic Link:
-
Notability:3
Description
After Nexus 3.32.0-03 the Content Type of newly downloaded NPM package (tgz) file is showing as "application/gzip" instead of "application/x-tgz". Earlier in Nexus 3.32 or prior releases, it was showing the content type as 'application/x-tgz'.
Steps to Reproduce:
1. Setup Nexus 3.32.0-03 npm proxy repo.
2. Try pulling an example package "launchdarkly-js-client-sdk/-/launchdarkly-js-client-sdk-2.16.3.tgz" from nexus.
3. Check the Content-Type: application/x-tgz in the curl output.
# curl -LOv -u admin:admin123 http://master.example.com:8081/repository/npm-group/launchdarkly-js-client-sdk/-/launchdarkly-js-client-sdk-2.16.3.tgz % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 127.0.1.1:8081... * TCP_NODELAY set * Connected to master.example.com (127.0.1.1) port 8081 (#0) * Server auth using Basic with user 'admin' > GET /repository/npm-group/launchdarkly-js-client-sdk/-/launchdarkly-js-client-sdk-2.16.3.tgz HTTP/1.1 > Host: master.example.com:8081 > Authorization: Basic YWRtaW46YWRtaW4xMjM= > User-Agent: curl/7.68.0 > Accept: */* > 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Mark bundle as not supporting multiuse < HTTP/1.1 200 OK < Date: Tue, 01 Mar 2022 21:33:33 GMT < Server: Nexus/3.32.0-03 (PRO) < X-Content-Type-Options: nosniff < Content-Security-Policy: sandbox allow-forms allow-modals allow-popups allow-presentation allow-scripts allow-top-navigation < X-XSS-Protection: 1; mode=block < Last-Modified: Thu, 06 Feb 2020 00:43:28 GMT < ETag: "fa30d251f15af70f4b82517c4dcdeef8" < Content-Type: application/x-tgz < Content-Length: 140957 < { [32768 bytes data] 100 137k 100 137k 0 0 207k 0 --:--:-- --:--:-- --:--:-- 207k * Connection #0 to host master.example.com left intact
4. Upgrade Nexus later versions like 3.34 / 3.35 or 3.37.3 and then perform the same test again. (OR) Perform the same test with a fresh installation of later Nexus Repository Manager version (like 3.34 / 3.35 or 3.37.3).
NOTE: If upgrading nexus repository manager, then make sure to delete the already cached package "launchdarkly-js-client-sdk-2.16.3.tgz" from the repository if it is already cached in nexus before the upgrade. Else the asset attribute would already be stored in the Nexus DB and hence we would not be able to see the issue.
5. Notice the Content-Type: application/gzip in the curl output.
# curl -LOv -u admin:admin123 http://master.example.com:8081/repository/npm-group/launchdarkly-js-client-sdk/-/launchdarkly-js-client-sdk-2.16.3.tgz % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 127.0.1.1:8081... * TCP_NODELAY set * Connected to master.example.com (127.0.1.1) port 8081 (#0) * Server auth using Basic with user 'admin' > GET /repository/npm-group/launchdarkly-js-client-sdk/-/launchdarkly-js-client-sdk-2.16.3.tgz HTTP/1.1 > Host: master.example.com:8081 > Authorization: Basic YWRtaW46YWRtaW4xMjM= > User-Agent: curl/7.68.0 > Accept: */* > 0 0 0 0 0 0 0 0 --:--:-- 0:00:03 --:--:-- 0* Mark bundle as not supporting multiuse < HTTP/1.1 200 OK < Date: Tue, 01 Mar 2022 21:43:17 GMT < Server: Nexus/3.37.3-02 (PRO) < X-Content-Type-Options: nosniff < Content-Security-Policy: sandbox allow-forms allow-modals allow-popups allow-presentation allow-scripts allow-top-navigation < X-XSS-Protection: 1; mode=block < Last-Modified: Thu, 06 Feb 2020 00:43:28 GMT < ETag: "fa30d251f15af70f4b82517c4dcdeef8" < Content-Type: application/gzip < Content-Length: 140957 < { [32345 bytes data] 100 137k 100 137k 0 0 39942 0 0:00:03 0:00:03 --:--:-- 39942 * Connection #0 to host master.example.com left intact
The same thing can also be verified via Nexus UI browse node while checking the attributes of this asset.
Use Case Where This Causes a Problem
Our Bower builds don’t fail exactly, but they produce invalid results.
A bower.json file includes the LaunchDarkly client like this:
"launchdarkly-js-client-sdk": "https://nexus.example.com/nexus/repository/npmjs/launchdarkly-js-client-sdk/-/launchdarkly-js-client-sdk-2.16.3.tgz",
Note, the launchdarkly-js-client-sdk package is not available in the public Bower registry, and the work around is to load it from the npm repository with the aid of the bower-nexus3-resolver. So Bower downloads this .tgz file, and based on the mime type, it determines how to handle the file. When the mime type is “application/x-tgz”, it sees this as a tar gzipped file that it need to extract, and it correctly unpacks the file. However, because the Nexus repo server is now serving this file with the mime type “application/gzip”, Bower doesn’t attempt to unpack this file, and as a result, we are left with a directory that contains 2 files, .bower.json and index.tgz. From Bower’s perspective, it successfully retrieved the package, so it’s not a failure, but there are no .js files that get added to our bundle as a result.
Expected:
Result should be consistent even after we upgrade nexus, unless there was a justifiable reason that Repo changed its returned Content-Type for NPM tgz files.
Attachments
Issue Links
- relates
-
NEXUS-11226 Better Strict Content Type Validation
-
- Ready to Groom
-