Validate Redirects During Android Model Downloads

Direct answer

A model downloader should treat redirects as changes to the response path that require policy checks, not as proof that the destination is trusted. Record the original artifact identity, each redirect status and target, the final scheme and host, response status, content type, range metadata, and the release metadata expected by the client. Reject destinations outside the documented origin policy, unexpected protocol downgrades, malformed responses, and any body that cannot be tied to the same artifact revision. Only then may the client decide whether it can write or resume bytes. A successful TLS connection to a redirected host only authenticates that host according to the platform trust chain; it does not prove that the host is an authorized distributor of this model. The local ModelDownloader currently configures HttpURLConnection to follow redirects automatically and then accepts HTTP 200 or 206. The observed code logs the final URL after connection but does not implement a host allowlist or check Content-Type before writing the response stream. Its Range request is based on the temporary file length; the fact card says it requests resume and writes a temporary file. The current code and fact card do not show a complete validator-bound, cross-origin redirect policy. This is a source review observation, not evidence that the app has received a hostile redirect or that its configured endpoints are compromised. A safe guide should explain what needs to be tested rather than label a particular string a common error. Redirect status semantics differ. Some redirect responses preserve the method, while others historically allow a client to change method behavior; clients also differ in how they forward headers and credentials. Even if the request contains no user credentials today, reusable download code should not assume every future caller is unauthenticated. Do not forward authorization or cookies to another origin unless the security design explicitly permits it. Do not place long-lived bearer tokens in query parameters likely to appear in logs. Validate scheme, host, port, and any allowed path relationship against release policy, and stop on an unrecognized target instead of following a chain indefinitely. Response status alone is not enough. A captive portal or proxy can return a successful HTML page; a mirror can return a different model revision; a server can ignore a Range request and return a full 200 response; a content encoding can make byte offsets ambiguous if the downloader expects identity encoding. Check status, content type, content length, range start and end, total representation length, validators, and final artifact digest when trusted metadata exists. When resuming, the response's range must begin exactly at the persisted offset and belong to the same representation. If it does not, write to a fresh temporary file or reject the attempt. Never append first and inspect later. An origin policy should be explicit and maintainable. Pin a repository owner and immutable revision in release metadata; if mirrors are permitted, list their exact origins and define how byte identity is verified. A broad suffix rule can accidentally authorize unrelated hosts, while pinning a single hostname can make a legitimate host change impossible without an app update. Prefer signed or otherwise trusted metadata that names the artifact and permitted source policy, but do not claim signature verification unless the implementation performs it. The current code's configured mirror is a second URL; that alone does not prove the mirror content matches the primary. A user-visible error should identify that the response was rejected by policy without exposing full private URLs or raw response bodies. Test with a controlled local or staging server, never with a real user's download endpoint. Fixtures should include same-origin redirect, approved mirror redirect, unapproved host, HTTPS-to-HTTP downgrade, redirect loop, HTML response with status 200, 404/5xx, invalid or ignored Range, changed artifact revision, truncated body, and a redirect with sensitive header handling. For each case, assert no unauthorized host is contacted, no untrusted body enters the final path, partial data is preserved or discarded according to policy, and the previous active model remains untouched. Capture the final host and response class in privacy-safe diagnostics. A single happy-path download through one endpoint cannot establish the redirect policy. ### Procedure 1. Write the origin policy. Identify the authoritative artifact repository, pinned revision, permitted mirrors, schemes, hosts, ports, and path constraints. Treat any change to this policy as a release review item. 2. Decide redirect handling explicitly. Either disable automatic following and validate each hop, or use a documented client policy that exposes enough information to enforce origin and credential rules. Bound the number of hops and reject downgrades or unexpected origins. 3. Validate response before writing. Check status, content type, range metadata, length, encoding policy, final representation identity, and trusted digest availability. Never open an append stream until the response matches the persisted artifact offset and revision. 4. Isolate candidate data. Write only to a revision-bound temporary path, preserve an already active verified model, and promote the candidate only after required checks pass. On mismatch, quarantine or delete candidate bytes without touching user data. 5. Exercise adversarial fixtures and audit logs. Test redirects, portal pages, stale mirrors, loops, and range errors; confirm diagnostics omit credentials, private inputs, and sensitive URL parameters. ### Acceptance criteria - Every redirect destination is checked against a documented scheme, origin, and artifact-source policy before its body is trusted. - Sensitive authorization material is not forwarded across an unapproved origin, and downgrade or loop behavior is bounded and tested. - Status, content type, and range metadata are validated before bytes are written or appended. - An unexpected response cannot replace the active artifact or be marked ready; failure preserves unrelated user data and produces a recoverable state. ### Comparison | Check | Establishes | Does not establish | |---|---|---| | TLS connection to final host | The connection meets platform certificate validation for that host | That the host is authorized to distribute the requested artifact | | HTTP status and content type | Basic response classification | Exact artifact identity or complete byte integrity | | Pinned revision plus trusted digest | Expected source and byte match when verified | Model compatibility or device performance | ### FAQ **Is it safe to follow every HTTPS redirect?** No. HTTPS protects the connection to each host but does not authorize each host as a model distributor. Validate the redirect chain against the release source policy and avoid forwarding sensitive credentials across origins. **Can a 200 response be treated as a model file?** Not by status alone. A portal or proxy can return HTML with a successful status. Validate content type and artifact metadata, then verify the resulting bytes before promotion. **What should happen if a resumed request is redirected to a different mirror?** Accept it only if that mirror is explicitly permitted and the response proves it serves the same pinned representation and requested range. Otherwise discard or quarantine the candidate partial data and restart under policy. **Does a matching file length prove the redirected download is correct?** No. Length can detect some truncation or mismatch cases but does not identify the publisher or establish byte equality. Use trusted artifact identity and digest verification when available.

A resumed request reaches a different host than expected

A model transfer was interrupted after some bytes were saved. On retry, an automatic redirect sends the request through a mirror or intermediary. The app must decide whether the final response belongs to the same artifact before it appends to the partial file.

Decision

Validate the redirect chain and final response against a documented source policy, then match range and artifact metadata before writing. Preserve the existing active model while evaluating the candidate.

Expected outcome

The client either accepts a permitted, matching representation or rejects the response without mixing bytes, leaking credentials, or replacing the working artifact.

Evidence to collect

The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:

• Redirect chain and final host
• Range and response-body fixtures
• Trust, reject, and recovery result

A completed byte stream is not enough. Final placement, integrity, runtime load, and recovery must also pass.

Implementation workflow

1. Define allowed source origins. Record the authoritative repository, immutable revision, permitted mirrors, HTTPS policy, host and port rules, and any permitted path scope. Do not treat every subdomain or every URL returned by a redirect as an approved source.
2. Inspect each redirect hop. Use a client flow that exposes redirect status and destination, or a documented policy that enforces the same checks. Bound the hop count, reject downgrade to cleartext, and do not forward authorization material to a different origin unless expressly allowed.
3. Classify the final response before writing. Check status, content type, content encoding policy, length, range start/end, total representation, and artifact revision. Treat a portal HTML page or unexpected full response as a rejected candidate, not as model bytes.
4. Protect resume and active-file state. Match the returned representation and range to the saved partial offset before append. Write only to an isolated revision-bound temporary file; keep the active model untouched until all required integrity and load checks pass.
5. Run controlled redirect fixtures. Exercise allowed and forbidden origins, loops, status changes, HTML responses, ignored ranges, mirror revision mismatch, truncation, and sensitive header behavior on a staging server. Inspect both network contact and the final file state.

Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.

Acceptance criteria

• All redirect hops and the final origin follow an explicit source policy before response bytes are trusted.
• Range and artifact identity are verified before resuming; unapproved or changed representations are not appended.
• Sensitive credentials are not sent to unauthorized origins and cleartext downgrade is rejected.
• A rejected response never replaces the active artifact or removes unrelated user data.

Decision table

Failure patterns to prevent

• Trusting a 200 HTML response as a model
• Allowing redirects to change artifact identity

Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.

Minimum reproducibility record

Release checklist

• ☐ The primary query is answered without an unsupported number.
• ☐ Every artifact and runtime is pinned.
• ☐ The representative task and failure policy are explicit.
• ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
• ☐ User-content and network boundaries are documented.
• ☐ Result wording applies only to the recorded configuration.
• ☐ The page links to raw method or evidence when results are added.

Sources and related evidence

• IETF HTTP Semantics: redirection and range requests
• Android HttpURLConnection API reference
• Android Network Security Configuration

Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.

Frequently asked questions