Context
#4262 was closed as wontfix: Publisher will not follow HTTP redirects with credentials across origin changes, and #4315 fixes the common case (http→https upgrade) by resolving redirects once at credential-creation time and storing the post-redirect URL.
That leaves stale credentials — created before #4315 lands, or pointing at servers that later add an [HTTPRedirect] config or migrate to a new host. When such a credential is used to publish, the failure messages are misleading:
- Host change (e.g. server migration): axios's
follow-redirects transport strips Authorization when the redirect crosses to a different, non-subdomain host, so the first publish request (GET /__api__/v1/user) follows the redirect unauthenticated and gets a 401. The user sees "authorization failed," which is misleading — their API key is fine; their credential URL is stale.
- http→https upgrade on the same host:
follow-redirects preserves Authorization on an https upgrade, so every preflight request silently succeeds, and the publish fails at the bundle upload (the one request with maxRedirects: 0) with Unexpected response from the server (302: ...) — no hint that a redirect occurred or where it pointed.
Proposal
Detect 3xx responses and surface an actionable error, e.g.:
Your server URL redirects to https://…. Update your credential's server URL and try again.
At minimum this should cover:
testAuthentication (catches host-change redirects before auth is stripped mid-flight — a 3xx with maxRedirects: 0 on this probe, or inspection of the final URL, would reveal the redirect)uploadBundle in @posit-dev/connect-api, where a 3xx currently falls into the generic "Unexpected response" branch of classifyDeploymentError
No redirect should be followed with credentials attached; the goal is purely a better error message pointing the user at the fix.
Context
#4262 was closed as wontfix: Publisher will not follow HTTP redirects with credentials across origin changes, and #4315 fixes the common case (http→https upgrade) by resolving redirects once at credential-creation time and storing the post-redirect URL.
That leaves stale credentials — created before #4315 lands, or pointing at servers that later add an
[HTTPRedirect]config or migrate to a new host. When such a credential is used to publish, the failure messages are misleading:follow-redirectstransport stripsAuthorizationwhen the redirect crosses to a different, non-subdomain host, so the first publish request (GET /__api__/v1/user) follows the redirect unauthenticated and gets a 401. The user sees "authorization failed," which is misleading — their API key is fine; their credential URL is stale.follow-redirectspreservesAuthorizationon an https upgrade, so every preflight request silently succeeds, and the publish fails at the bundle upload (the one request withmaxRedirects: 0) withUnexpected response from the server (302: ...)— no hint that a redirect occurred or where it pointed.Proposal
Detect 3xx responses and surface an actionable error, e.g.:
At minimum this should cover:
testAuthentication(catches host-change redirects before auth is stripped mid-flight — a 3xx withmaxRedirects: 0on this probe, or inspection of the final URL, would reveal the redirect)uploadBundlein@posit-dev/connect-api, where a 3xx currently falls into the generic "Unexpected response" branch ofclassifyDeploymentErrorNo redirect should be followed with credentials attached; the goal is purely a better error message pointing the user at the fix.