[RTFACT-15016] Artifactory is not returning Cache-Control header for -SNAPSHOT/sha1/.jar artifacts Created: 28/Sep/17  Updated: 07/Sep/18  Resolved: 21/Aug/18

Status: Resolved
Project: Artifactory Binary Repository
Component/s: None
Affects Version/s: 5.5.1
Fix Version/s: 6.4.0

Type: Bug Priority: Normal
Reporter: Guy Cohen Assignee: Dudi Morad (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 3 days, 1 hour
Time Spent: 1 day, 7 hours
Original Estimate: 1 week

Estimated Resolution Quarter: Q3-18
Support Tickets:

Atlassian - Support Case, Atlassian - Support Case
Product Comments: ETA is Q2-18.
Sprint: Leap 34
Support Rep(s):
Guy Cohen
Reviewer:
Gal Ben Ami

 Description   

This appears to be a regression for RTFACT-6983
Here is the expected response with maven-metadata.xml file (includes Cache-Control header and value):

curl -vvv -X GET http://localhost:8080/artifactory/libs-snapshot-local/org/jfrog/test/multi/3.8-SNAPSHOT/maven-metadata.xml -uadmin:password
Note: Unnecessary use of -X or --request, GET is already inferred.

  • Trying ::1...
  • TCP_NODELAY set
  • Connected to localhost (::1) port 8080 (#0)
  • Server auth using Basic with user 'admin'
    > GET /artifactory/libs-snapshot-local/org/jfrog/test/multi/3.8-SNAPSHOT/maven-metadata.xml HTTP/1.1
    > Host: localhost:8080
    > Authorization: Basic YWRtaW46cGFzc3dvcmQ=
    > User-Agent: curl/7.52.1
    > Accept: /
    >
    < HTTP/1.1 200 OK
    < Server: Artifactory/development
    < X-Artifactory-Id: 6899d0e9806c9547:-670f853d:15eb8db23c8:-8000
    < Last-Modified: Tue, 08 Aug 2017 08:24:46 GMT
    < ETag: 858f1bec094673de359d0cc5bb0ccb1d97a67fef
    < X-Checksum-Sha1: 858f1bec094673de359d0cc5bb0ccb1d97a67fef
    < X-Checksum-Sha256: 58301909fe9f059d5f2a506e0a9fa19dc93c8a7b14541d2314212d6b73c279b4
    < X-Checksum-Md5: 3da61b98df8ad3dccadcb92fb6b98594
    < Accept-Ranges: bytes
    < X-Artifactory-Filename: maven-metadata.xml
    < Content-Disposition: attachment; filename="maven-metadata.xml"; filename*=UTF-8''maven-metadata.xml
    < Cache-Control: no-store
    < Content-Type: application/xml
    < Content-Length: 594
    < Date: Wed, 27 Sep 2017 09:15:27 GMT

Here is the response without Cache-Control header (for '-SNAPSHOT' suffix)
curl -vvv -X GET http://localhost:8080/artifactory/libs-snapshot-local/org/jfrog/test/multi/3.8-SNAPSHOT/multi-3.8-20170222.201153-11.pom -uadmin:password
Note: Unnecessary use of -X or --request, GET is already inferred.

  • Trying ::1...
  • TCP_NODELAY set
  • Connected to localhost (::1) port 8080 (#0)
  • Server auth using Basic with user 'admin'
    > GET /artifactory/libs-snapshot-local/org/jfrog/test/multi/3.8-SNAPSHOT/multi-3.8-20170222.201153-11.pom HTTP/1.1
    > Host: localhost:8080
    > Authorization: Basic YWRtaW46cGFzc3dvcmQ=
    > User-Agent: curl/7.52.1
    > Accept: /
    >
    < HTTP/1.1 200 OK
    < Server: Artifactory/development
    < X-Artifactory-Id: 6899d0e9806c9547:-670f853d:15eb8db23c8:-8000
    < Last-Modified: Wed, 22 Feb 2017 20:12:00 GMT
    < ETag: a04bae375d04d0f904baa700a5d3bc74e210c35c
    < X-Checksum-Sha1: a04bae375d04d0f904baa700a5d3bc74e210c35c
    < X-Checksum-Sha256: 7b1b113be7f7867c7d892753875e1d5ff1bcf67b75f475c1539ed3d064900933
    < X-Checksum-Md5: 8821159fe2109cce36a280570025a565
    < Accept-Ranges: bytes
    < X-Artifactory-Filename: multi-3.8-20170222.201153-11.pom
    < Content-Disposition: attachment; filename="multi-3.8-20170222.201153-11.pom"; filename*=UTF-8''multi-3.8-20170222.201153-11.pom
    < Content-Type: application/x-maven-pom+xml
    < Content-Length: 2721
    < Date: Wed, 27 Sep 2017 09:16:42 GMT

Another response without Cache-Control header
curl -vvv -X GET http://localhost:8080/artifactory/maven-local/com/google/guava/guava/18.0/guava-18.0.jar -uadmin:password
Note: Unnecessary use of -X or --request, GET is already inferred.

  • Trying ::1...
  • TCP_NODELAY set
  • Connected to localhost (::1) port 8080 (#0)
  • Server auth using Basic with user 'admin'
    > GET /artifactory/maven-local/com/google/guava/guava/18.0/guava-18.0.jar HTTP/1.1
    > Host: localhost:8080
    > Authorization: Basic YWRtaW46cGFzc3dvcmQ=
    > User-Agent: curl/7.52.1
    > Accept: /
    >
    < HTTP/1.1 200 OK
    < Server: Artifactory/development
    < X-Artifactory-Id: 6899d0e9806c9547:-670f853d:15eb8db23c8:-8000
    < Last-Modified: Wed, 27 Sep 2017 08:45:35 GMT
    < ETag: cce0823396aa693798f8882e64213b1772032b09
    < X-Checksum-Sha1: cce0823396aa693798f8882e64213b1772032b09
    < X-Checksum-Sha256: d664fbfc03d2e5ce9cab2a44fb01f1d0bf9dfebeccc1a473b1f9ea31f79f6f99
    < X-Checksum-Md5: 947641f6bb535b1d942d1bc387c45290
    < Accept-Ranges: bytes
    < X-Artifactory-Filename: guava-18.0.jar
    < Content-Disposition: attachment; filename="guava-18.0.jar"; filename*=UTF-8''guava-18.0.jar
    < Content-Type: application/java-archive
    < Content-Length: 2256213
    < Date: Wed, 27 Sep 2017 09:11:33 GMT

 Comments   
Comment by Atlassian Build Team [ 05/Oct/17 ]

The issues we have are:

Artifactory does NOT send response header "Cache-control: no-store" for *-SNAPSHOT/maven-metadata.xml.sha1. But it SHOULD.

Artifactory does NOT send "Cache-Control: no-store" for *-SNAPSHOT.jar. But it SHOULD.

Artifactory does NOT send "Cache-control: no-store" for ?trace requests, but it SHOULD.

For snapshot with timestamps in it's file name, e.g "multi-3.8-20170222.201153-11.pom", I think it is probably OK to NOT send the no-store header. Also it is ok to NOT send no-store header for non-snapshot versions, e.g. "guava-18.0.jar "

Comment by Atlassian Build Team [ 05/Oct/17 ]

I mean it is correct to NOT send "no-store" for timestamped artifacts and non-snapshot artifacts.

Comment by Atlassian Build Team [ 05/Oct/17 ]

Another issue: artifactory does not send no-store header for metadata of npm packages, but it SHOULD.
E.g. when I curl http://artifactory/api/npm/repo/artifactName, the response contains available versions and links to tarballs of my artifact. This file is updated every time a new version is published. However, artifactory does not send no-store header, my reverse proxy will cache the response and cause npm not able to download latest version.

Comment by Manoj Tuguru [ 25/Jan/18 ]

The same behavior occurs for the debian repositories as well:
curl -vvv "http://localhost:8081/artifactory/rpm/2.1/centos2-scripts-v1.tar"

  • Trying ::1...
  • TCP_NODELAY set
  • Connected to localhost (::1) port 8081 (#0)
    > GET /artifactory/rpm/2.1/centos2-scripts-v1.tar HTTP/1.1
    > Host: localhost:8081
    > User-Agent: curl/7.54.0
    > Accept: /
    >
    < HTTP/1.1 200 OK
    < Server: Artifactory/5.8.3
    < X-Artifactory-Id: a29ad6c26d380d2f:-62e95ce9:1612e72ab1d:-8000
    < Last-Modified: Wed, 09 Sep 2009 05:12:58 GMT
    < ETag: d3d406d1e54159808d102358188f875fcc8c8102
    < X-Checksum-Sha1: d3d406d1e54159808d102358188f875fcc8c8102
    < X-Checksum-Sha256: 34011672f606d9c7399a4f69ca1143c2355407879b6fb3e8efba380039958bf1
    < X-Checksum-Md5: b06ecfea560048696078824e4d6903de
    < Accept-Ranges: bytes
    < X-Artifactory-Filename: centos2-scripts-v1.tar
    < Content-Disposition: attachment; filename="centos2-scripts-v1.tar"; filename*=UTF-8''centos2-scripts-v1.tar
    < Content-Type: application/x-tar
    < Content-Length: 1249280
    < Date: Thu, 25 Jan 2018 17:56:56 GMT
Comment by Atlassian Build Team [ 21/Feb/18 ]

Another 2 files that should not be cached but artifactory does not send "Cache-control: no-store" header.

https://myArtifactory.com/myDebianRepo/dists/xenial/Release
https://myArtifactory.com/myDebianRepo/dists/xenial/Release.gpg
Comment by Atlassian Build Team [ 08/Mar/18 ]

Another case

https://myArtifactory.com/myDebianRepo/dists/xenial/PC1/binary-amd64/Packages.gz(.sha1|.md5)
Comment by Atlassian Build Team [ 23/Mar/18 ]

Another case

https://myArtifactory.com/myYumRepo/repodata.xml(.asc|.key)
Comment by Atlassian Build Team [ 27/Mar/18 ]

Can we also stop caching trace requests? E.g.

http://myartifactory/maven-local/com/mycompany/myartifact/1.0.0/myartifact-1.0.0.pom?trace
Comment by Atlassian Build Team [ 28/May/18 ]

Hi there,

 

We are on Artifactory 5.10.3. I can confirm that maven/apt/yum metadata has been fixed. However, npm/pypi and trace requests are still not fixed yet. E.g.

https://myinstance/myinstance/api/npm/npm-repo/package
https://myinstance/myinstance/pypi/simple/acorn/
https://myinstance/myinstance/maven/com/test/1.0/test-1.0.jar?trace
Generated at Sun Dec 15 04:03:36 UTC 2019 using JIRA 7.6.16#76018-sha1:9ed376192612a49536ac834c64177a0fed6290f5.