A Saved File Is Not Yet a Verified Download

A hypothetical report.xlsx is 8 KB and opens as a login page. The program saved a file successfully, but it never obtained the intended spreadsheet. A filename is chosen locally; it is not evidence of what arrived.

Make acceptance a separate step before publishing the temporary download:

1. Require a successful transfer and expected response status. Preserve an error rather than treating the bytes written before it as complete.
2. Compare the content with the expected artifact type. A login or filter page may return 200. Content-Type can be wrong, and an HTML prefix in a spreadsheet is a warning that needs investigation. A file starting with an HTTP status line points to raw-response framing instead.
3. Validate the complete saved bytes against a trusted checksum or signature when available. Only after the required checks pass should the application publish or use the final file.

Calculating a hash without an expected value only identifies the bytes you received. An unsigned checksum fetched through the same untrusted path can share the artifact's weakness; use an independent trusted expectation.

Take care with size comparisons too. An HTTP client may decode content encoding while reading, so the resulting file length may legitimately differ from a header describing the encoded message. Compare the publisher's artifact expectation with the representation actually saved.

If an attempt fails, retain the temporary output only for a deliberate resume or discard it. Leaving incomplete bytes at the final path forces the next program to guess whether they are usable.