Search code examples
curlhttp-status-code-404artifactory

Artifactory cURL download returns 404 File Not Found error when artefact file exists in repository

I'm using Artifactory for build artifact storage in my CICD pipeline.

I've scripted the artifact push to repository using a cURL API call in PowerSHell script:

curl.exe -H "X-JFrog-Art-Api: $apiKey" -X PUT $repoUrl -T $artifactFilePath

This executed successfully and the artifact file is deposited in the specified Artifactory repository as expected.

Later, I've attempted to download the same artifact file using the following cURL API call:

curl.exe -H "X-JFrog-Art-Api: $apiKey" -X GET $artifactUrl

Even though I can browse the Artifactory GUI and clearly see the artifact file in the subrepository, execution of the GET request returns:

{
  "errors" : [ {
    "status" : 404,
    "message" : "File not found."
  } ]
}

I've checked and double-checked that he repository path is correct (it is consistent with the path in the initial upload request). I've used the same API key for each request and have confirmed that the associated functional ID has read, write, annotate and delete permissions in the repository.

I've been working with this for some hours now and have so far been unable to identify or solve the problem. Insights or advice on this issue would be most welcome.

UPDATE:

Execution of cURL request with '-v- switch for verbose output returns:

  • Connected to www.[Artifactory URL].net (169.177.244.86) port 443 (#0)
  • schannel: SSL/TLS connection with www.[Artifactory URL].net port 443 (step 1/3)
  • schannel: checking server certificate revocation
  • schannel: sending initial handshake data: sending 201 bytes...
  • schannel: sent initial handshake data: sent 201 bytes
  • schannel: SSL/TLS connection with www.[Artifactory URL].net port 443 (step 2/3)
  • schannel: failed to receive handshake, need more data
  • schannel: SSL/TLS connection with www.[Artifactory URL].net port 443 (step 2/3)
  • schannel: encrypted data got 2415
  • schannel: encrypted data buffer: offset 2415 length 4096
  • schannel: sending next handshake data: sending 126 bytes...
  • schannel: SSL/TLS connection with www.[Artifactory URL].net port 443 (step 2/3)
  • schannel: encrypted data got 290
  • schannel: encrypted data buffer: offset 290 length 4096
  • schannel: SSL/TLS handshake complete
  • schannel: SSL/TLS connection with www.[Artifactory URL].net port 443 (step 3/3)
  • schannel: stored credential handle in session cache

    GET /[Artifactory repo]/[Artifactory repo path]/[artifact file name].txt HTTP/1.1 Host: www.[Artifactory URL].net User-Agent: curl/7.55.1 Accept: / X-JFrog-Art-Api: [API key] 0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- 0:00:02 --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- 0:00:03 --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- 0:00:04 --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- 0:00:05 --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- 0:00:06 --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- 0:00:07 --:--:-- 0

  • dud
  • schannel: client wants to read 102400 bytes
  • schannel: encdata_buffer resized 103424
  • schannel: encrypted data buffer: offset 0 length 103424
  • schannel: encrypted data got 1144
  • schannel: encrypted data buffer: offset 1144 length 103424
  • schannel: decrypted data length: 1115
  • schannel: decrypted data added: 1115
  • schannel: decrypted data cached: offset 1115 length 102400
  • schannel: encrypted data buffer: offset 0 length 103424
  • schannel: decrypted data buffer: offset 1115 length 102400
  • schannel: schannel_recv cleanup
  • schannel: decrypted data returned 1115
  • schannel: decrypted data buffer: offset 0 length 102400 < HTTP/1.1 200 OK < Date: Wed, 19 Feb 2020 17:04:58 GMT < Content-Type: text/plain < Content-Length: 3 < Connection: keep-alive < Server: Artifactory/6.16.0 < X-Artifactory-Id: d9260ad7ca1d26ab34fdd4717e47fdd9abc8e83f < X-Artifactory-Node-Id: prodnode3 < Last-Modified: Thu, 23 Jan 2020 15:30:10 GMT < ETag: 7744ffc8156c74a9ce68f9cc621ac37624549928 < X-Checksum-Sha1: 7744ffc8156c74a9ce68f9cc621ac37624549928 < X-Checksum-Sha256: b4fae8fae2070cbb6c52c22baf32eb1995be678f93e760dfddb60b166bd1a90f < X-Checksum-Md5: 807dfcc396f827846e9631b735c7e808 < Accept-Ranges: bytes < X-Artifactory-Filename: [artifact file name].txt < Content-Disposition: attachment; filename="[artifact file name].txt"; filename*=UTF-8''[artifact file name].txt < X-Frame-Options: DENY < X-Content-Type-Options: nosniff < X-XSS-Protection: 1; mode=block < Strict-Transport-Security: max-age=31536000; includeSubdomains; preload < Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'self' data: ; style-src 'self' 'unsafe-inline'; font-src 'self' data: https://themes.googleusercontent.com; object-src 'none' < { [3 bytes data] 100 3 0 3 0 0 0 0 --:--:-- 0:00:08 --:--:-- 0100 3 0 3 0 0 0 0 --:--:-- 0:00:08 --:--:-- 0
  • Connection #0 to host www.[Artifactory URL].net left intact Blockquote
Solution

  • The original 404 issue was apparently due to an error in my artifact URL in the original cURL API call.

    The logs above show the call return after the URL had been rectified. Even with the correct artifact path, the file did not appear to be downloading as expected. Note, the 'dud' in the above verbose call log is the content of the text file, implying that the file is found and successfully read.

    In the end, addition of the '--output' switch, with filename specified, resulted in successful artifact file download.