correctly handle redirects on bundle upload

[christierney]

To support streaming of large bundles, we had to disable Axios' automatic following of redirects. (#4249)

I believe prior to 2.0.0, publisher did not handle redirects (#18, #2372), and as far as I know we have not done specific testing of redirect handling with 2.x. However, this is still arguably a regression.

Other Connect clients have added custom redirect handling:

• feat: forward POST body with 3xx redirection statues posit-sdk-py#385
• libCurl HTTP handler doesn't handle redirects rstudio/rsconnect#674
• deployApp() fails with "bad checksum" when uploading bundle to shinyapps.io rstudio/rsconnect#1297

We should investigate whether something similar would work here.

For bundle uploads specifically, we should start a new stream from disk every time we make an upload request; we must not buffer the bundle in memory nor drop the POST body on retry.

[joshyam-k]

@christierney is this one that you're going to work on next? trying to decide whether to move this to your teams board or keep it in intake. Thanks!

[christierney]

I can take this one.

[christierney]

Closing this as wontfix after investigating. Summary: the redirect cases that motivated
this issue are origin changes, and forwarding Authorization across an origin change is
the wrong behavior — the fix for the real-world scenarios belongs at credential-creation
time (#4315), not in publish-time redirect following.

What actually happens today

Every Publisher request to Connect carries Authorization (API key or signed token).
On main, only the bundle upload sets maxRedirects: 0 (to keep axios on its native
transport so large bundles truly stream — see #4249); every other request goes through
axios's default follow-redirects transport. So when a stored credential URL redirects:

• Host change (e.g. a server migration): follow-redirects strips Authorization
  when the redirect crosses to a different, non-subdomain host, so the very first
  publish request (GET /__api__/v1/user) follows the redirect unauthenticated, gets a
  401, and the publish fails at "Testing authentication." We never reach the upload.
• http→https upgrade on the same host (Connect's [HTTPRedirect]):
  follow-redirects preserves Authorization on an https upgrade, so the preflight
  requests all succeed and the publish fails at the bundle upload with an opaque
  Unexpected response from the server (30x: ...).
• Token-auth (signed) credentials break on any path-changing redirect regardless,
  because the request signature is computed once over the original path.

Why redirect following isn't the right fix

Following these redirects "correctly" would mean replaying the streamed bundle body
and re-supplying Authorization to a new origin. The reference implementations
refuse to do the latter:

• Python requests strips Authorization on any hostname change, and on scheme/port
  changes except the standard-port http:80→https:443 upgrade — so the typical Connect
  [HTTPRedirect] setup (:3939→:3443) is stripped even by requests.
• curl (post-CVE-2022-27774) strips credentials on any host, protocol, or port change
  unless --location-trusted.
• posit-sdk-py is converging on the same policy: fix(connect): strip Authorization on cross-origin redirects in custom Session posit-sdk-py#464 strips
  Authorization on any scheme/host/port mismatch.

So even with full redirect-following machinery, the motivating cases would end in a 401
on the post-redirect origin. The correct user action for an origin change is to update
the credential's server URL, and Publisher should not paper over that by silently
forwarding credentials.

What covers the real-world cases instead

• Cannot create a credential for a Connect server that redirects http to https #4315 fixes this at the root for http→https: resolve redirects once,
  unauthenticated, while validating the server URL at credential creation, and store
  the post-redirect URL. After that, publish-time requests never see the redirect at
  all, bundle upload included.
• Server migrations require a manual credential update, which is the policy this
  wontfix adopts.

Follow-ups carved out of this issue

1. Stale credentials (created before Cannot create a credential for a Connect server that redirects http to https #4315, or servers that add a redirect later) will
   hit the failure modes above, and both messages are bad — a misleading
   "authorization failed" for host changes, and an opaque "Unexpected response (302)"
   at upload. Surface an actionable error when the Connect server URL redirects #4316 tracks detecting a 3xx response and surfacing the Location
   target with guidance to update the credential URL.
2. This wontfix also drops the same-origin case (a path-only redirect on the upload,
   e.g. a proxy rewrite), where no credential concern applies but restreaming the
   bundle from disk would be needed. No evidence this occurs in practice; can revisit
   if a report surfaces.
3. The Connect Cloud presigned-URL upload also sets maxRedirects: 0 and would
   hard-fail on an S3-style region redirect, independent of this issue's policy
   question. We have not had any reports of this being a problem, so we are not
   filing an issue for it at this time.