There may be a use case where your automation or script wants to look at the returned result of a folder to parse through what is available and perform further action or analysis on the result. For example, a script that takes a folder records the available links in that folder, then follows through and requests particular items from those links.
Sending requests to folder locations of remote repositories will cache the returned result. In this case, it will catch the HTML response of the upstream repository. The following example is just a generic remote repository called “hashicorp-folders-remote”.
I.e. A curl request to a folder in the upstream
In Artifactory you will see that the HTML file has been cached at the 2.2.0 folder location.
On the upstream site, there are actual artifacts located within the “2.2.0” folder.
A request to one of those items will now fail since the “2.2.0” HTML response has been saved as a file
i.e. The Upstream contents of the “2.2.0” folder from the upstream site.
i.e. A request to Artifactory using the same repository will now fail since the earlier “2.2.0” request saved a file in the location of a folder upstream.
This is intended behavior. To remedy this we will have to account for both use cases; resolving folder locations and resolving files within those folders.
Sending requests to folder locations of remote repositories will cache the returned result. In this case, it will catch the HTML response of the upstream repository. The following example is just a generic remote repository called “hashicorp-folders-remote”.
I.e. A curl request to a folder in the upstream
$ curl -uadmin "<ART_URL>/artifactory/hashicorp-folders-remote/terraform-provider-template/2.2.0"
<!DOCTYPE html>
<html>
<head>
<title>Terraform Provider Template v2.2.0 Binaries | HashiCorp Releases</title>
<meta name=viewport content="width=device-width, initial-scale=1">
<style type="text/css">
html {
position: relative;
min-height: 100%;
…
<li>
<a data-product="terraform-provider-template" data-version="2.2.0" data-os="darwin" data-arch="amd64" href="https://releases.hashicorp.com/terraform-provider-template/2.2.0/terraform-provider-template_2.2.0_darwin_amd64.zip">terraform-provider-template_2.2.0_darwin_amd64.zip</a>
</li>
… In Artifactory you will see that the HTML file has been cached at the 2.2.0 folder location.
On the upstream site, there are actual artifacts located within the “2.2.0” folder.
A request to one of those items will now fail since the “2.2.0” HTML response has been saved as a file
i.e. The Upstream contents of the “2.2.0” folder from the upstream site.
i.e. A request to Artifactory using the same repository will now fail since the earlier “2.2.0” request saved a file in the location of a folder upstream.
$ curl -uadmin "<ART_URL>/artifactory/hashicorp-folders-remote/terraform-provider-template/2.2.0/terraform-provider-template_2.2.0_darwin_amd64.zip"
{
"errors" : [ {
"status" : 400,
"message" : "Parent terraform-provider-template/2.2.0 must be a folder"
} ]
} This is intended behavior. To remedy this we will have to account for both use cases; resolving folder locations and resolving files within those folders.