Overview
In certain versions of Artifactory (7.146.xx), downloading artifacts directly from the Artifactory web UI may fail. Instead of the requested binary artifact, the download endpoint returns an HTML page. This affects both anonymous users and authenticated, token-only users.
Symptoms & error messages
-
Clicking Download from the UI does not download the artifact.
-
The browser opens or downloads an HTML document instead of the expected binary file.
-
Download URLs generated from the UI use endpoints similar to:
-
/ui/native/...
-
/ui/repos/tree/...
-
The artifact exists in the repository and can still be downloaded successfully using the direct repository URL or REST API with Basic auth.
-
Variant (anonymous access, browser-visible): instead of a single failed download, the page enters a continuous reload loop, with repeated 403 errors on the MFE manifest request visible in the browser console/network tab:
/ui/api/v1/ml/frontend-mfe-server/static/manifest.js — 403
Cause
This issue is caused by an internal bug in the UI request routing mechanism, tracked as RTDEV-87580.
A browser GET to /artifactory/<repo>/<path> that reaches the auth filter chain without valid credentials is redirected (302) to /ui/native/<repo>/<path>, which serves the Artifactory SPA index.html shell rather than the requested binary. The browser, already in download mode from the original click, saves that HTML shell as the downloaded file.
This affects more than anonymous users. It affects any browser GET to /artifactory/... that arrives without a session cookie, which includes:
-
Anonymous access, the scenario this Jira was originally filed against.
-
Token-only authenticated users, the SPA sends Authorization: Bearer <token> on its own API calls, but when it triggers the actual file download by navigating the browser to /artifactory/..., the browser sends cookies only, not the token header. A token-only user therefore has no session cookie on that request, hits the same redirect, and gets the same broken download despite being logged in. Support bundles will show a non_authenticated_user entry on the download GET even though the user is a real, currently logged-in person, this reflects what that specific request carried, not the user's actual session state.
Affected downloads: confirmed for both the UI's native Download button flow and direct navigation to /artifactory/<repo>/<path> (for example via the Tree Browser or a shared link). The UI's own Download button (isNativeBrowsing=false) is not affected, only requests that resolve to a direct /artifactory/... browser navigation are.
Fix version:
-
Fixed in 7.146.25 for both cases, including the reload-loop/manifest-403 variant described above, since the SPA never bootstraps once the redirect no longer fires.
Please note:
if the workarounds below are applied, after upgrading it is recommended to revert them, as they may cause other unintended issues.
Step-by-step solution
Until a version-confirmed fix is available for your scenario, apply one of the following system properties in $JFROG_HOME/artifactory/var/etc/artifactory/artifactory.system.properties, then restart Artifactory.
Option 1 - for the anonymous-access scenario:
-
Open the following configuration file:
$JFROG_HOME/artifactory/var/etc/artifactory/artifactory.system.properties
-
Add the following property if it does not already exist, or update it if present:
artifactory.redirect.native.browser.requests.to.ui=false
-
Save the file.
-
Restart the Artifactory service for the change to take effect.
This disables the Native Browser Redirect entirely.
Option 2 - for the authenticated/token-only user scenario, or to restore the password prompt after Option 1:
-
Open the same configuration file:
$JFROG_HOME/artifactory/var/etc/artifactory/artifactory.system.properties
-
Add or update:
artifactory.response.skip.www.authenticate.header=false
-
Save the file.
-
Restart the Artifactory service for the change to take effect.
Which property to apply depends on whether the affected users are anonymous or authenticated, they are not interchangeable fixes for the same symptom.
Side effects to check before applying Option 1 on an SSO-only instance (SAML/OAuth):
With artifactory.redirect.native.browser.requests.to.ui=false set, anonymous access to /artifactory/... behaves correctly, but authenticated SSO users hitting /artifactory/<repo>/<path> directly will get a 401 instead of the file, because their SSO session cookie does not authenticate the /artifactory/ filter chain and there is no longer a redirect to compensate. /ui/native/<repo>/<path> still works for authenticated users but is not a documented user-facing path.
Side effect with anonymous access enabled and the default skip.www.authenticate.header value:
With the redirect disabled, an anonymous user hitting the Tree Browser may get a bare 401 instead of the expected password prompt, since artifactory.response.skip.www.authenticate.header defaults to true since 7.133.8. Remediate by either disabling Anonymous Access or setting artifactory.response.skip.www.authenticate.header=false.
Verification
-
Downloads initiated from the Artifactory UI correctly stream the requested binary artifact.
-
HTML pages are no longer returned in place of the artifact payload.
-
For the anonymous reload-loop variant, the page no longer enters a bootstrap/reload cycle.
Related resources