This workaround is relevant in cases where the gems/bundler client is configured against a virtual repository that contains both remote and local repositories. In this case, when the api/v1/dependencies request is executed, the local repository returns a 200 response with an empty list, whereas the remote returns a 404 response. As the repositories are aggregated in a virtual repository, the response that is returned to the client is the aggregation of the “200” and “404” responses, which eventually results in a successful “200” response. Due to this, the client does not fall back to the full index and the installation fails.
To overcome this, it is possible to modify Artifactory’s response for the api/v1/dependencies request to a “404” response instead of a “200” by adding a rewrite rule to the Reverse Proxy configuration.
The implementation can differ depending on the reverse proxy in use. An example can be found on this public Jira ticket - RTFACT-29525.
When the client is configured against the remote repository directly, or against a virtual repository that does not aggregate any local repositories, there is no need for the above-mentioned workaround and the fallback to full index should happen automatically by the client.
To overcome this, it is possible to modify Artifactory’s response for the api/v1/dependencies request to a “404” response instead of a “200” by adding a rewrite rule to the Reverse Proxy configuration.
The implementation can differ depending on the reverse proxy in use. An example can be found on this public Jira ticket - RTFACT-29525.
When the client is configured against the remote repository directly, or against a virtual repository that does not aggregate any local repositories, there is no need for the above-mentioned workaround and the fallback to full index should happen automatically by the client.