Titanium SDK 7.0/8.0: HTTPClient redirect header preservation diverges between NSURLSession and OkHttp backends

Short answer

On Titanium SDK 12.x there is no divergence to reconcile: both backends strip the Authorization header when following a redirect to a different origin (host, port, or scheme). iOS does it via NSURLSession's credential-leak protection, and Android does it via OkHttp's redirect follower, which implements the same rule. Neither validatesSecureCertificate=false nor setRequestHeader changes this, and the SDK exposes no redirect-policy API. The only supported route to parity with header preservation is manual redirect handling — which, as you suspected, costs you automatic connection reuse.

What is documented vs. what is observable

Confirmed: the 7.0.0 and 8.0.0 changelogs document the backend migrations (NSURLSession, OkHttp) but define no cross-platform redirect contract. Likely explanation, based on the underlying libraries' well-established defaults:

• iOS (NSURLSession): when a redirect crosses an origin boundary, the session removes the Authorization header before issuing the follow-up request. This is intentional credential-leak prevention, not a bug.
• Android (OkHttp): the built-in redirect follower also removes Authorization on cross-origin redirects, preserving it only when scheme, host, and port all match. Its redirect cap (historically 20) applies separately.

So the practical divergence you may have observed is usually in same-origin behavior, redirect limits, or cookie handling — not in cross-origin Authorization forwarding, where both stacks converge on stripping.

Do the knobs you mentioned help?

• validatesSecureCertificate=false only relaxes TLS chain validation. It has no effect on redirect header logic, and it carries real security risk — don't use it as a workaround here.
• setRequestHeader('Authorization', ...) sets the header on the initial request. The platform stack removes it after the redirect decision, so re-setting it before send() changes nothing for the redirected hop.

Supported pattern for parity

Since SDK 12.x offers no hook to inspect or override redirect policy, the reliable approach is to treat 3xx responses yourself:

1. Send the request and check this.status in onload for 301/302/303/307/308.
2. Read the Location response header, resolve it against the request URL, and enforce a redirect counter (e.g., max 5) to avoid loops.
3. Re-issue the request with setRequestHeader applied again — now the header survives because you control each hop.

Keep-alive still works at the platform layer for connections to the same host across your manual hops; what you lose is the single-call convenience and any intra-chain socket reuse the stack would have done. For an OAuth-style flow with one or two redirects, the added latency is typically one extra round trip — usually acceptable, but measure it if you chain many calls.

Verify before you commit

Because this behavior depends on the underlying libraries and could shift in future SDK releases, confirm it on your target versions:

1. Point an HTTPClient request with an Authorization header at an endpoint returning a 302 to a different host that echoes received headers.
2. Run on iOS and Android; expect Authorization to be absent at the final endpoint on both.
3. Repeat with validatesSecureCertificate=false and with an extra custom header to confirm neither changes the outcome.
4. Switch to manual handling and confirm the header now arrives.

One caveat: if your redirect target is actually same-origin (only the path changes) and you still see the header dropped, that would contradict the expected behavior — capture the echoed headers and the exact SDK version before redesigning around it.