Turbo Frame 302 redirect handling limits across browser versions

Turbo Frames are documented to follow HTTP redirects automatically when fetching a frame's source, replacing the frame content with the redirect target rather than triggering a full page navigation. In practice, browser implementations of fetch and XMLHttpRequest redirect handling may diverge from this documented behavior, particularly when a server returns a 302 response to a frame request.

The ambiguity arises because Turbo does not explicitly process the Location header for frame requests, leaving redirect resolution to the underlying browser fetch implementation. This raises an unresolved design question about whether Turbo should intercept redirects at the client level and issue a subsequent fetch to the new URL, or continue delegating to the browser's default redirect handling.

Version assumptions matter here: behavior observed in Chrome 120, Firefox 120, and Safari 16 may differ, and current verification is required before drawing conclusions. A custom redirect handler could also interfere with authentication flows that depend on cookies or CSRF tokens surviving the redirect.

Should Turbo Frames explicitly intercept 302 redirects for frame requests to guarantee consistent content replacement across browsers, or is delegating to native fetch redirect behavior the intended boundary? How should the library handle redirects when the target URL requires credentials or tokens that the original frame request carried? What testing matrix across recent browser versions is necessary to validate the documented redirect behavior?