Follow-up to #491, which was fixed in 4.8.5 by making mid-download
resume opt-in (safe default: fail and delete the staged file, since
switching networks can route a stable URL to a different CDN object).
That fix only changes what happens on a *real* read error. It doesn't
help if a transport surfaces a mid-transfer connection drop as a plain
io.EOF instead of io.ErrUnexpectedEOF - fileDownload's copyBody loop
still breaks out and promotes the file on any clean EOF, regardless of
whether written bytes actually reached Content-Length. This app's
uTLS-based client (used for TLS-fingerprint spoofing) is exactly the
kind of custom transport where that guarantee isn't necessarily upheld.
Now a clean EOF short of a known Content-Length is routed through the
same resume-or-fail path as a real read error, so it respects the same
opt-in `resume` option: fails and cleans up the staged file by default,
or resumes via Range/If-Range when the caller explicitly requested it
and the server provided a validator.
extension_runtime_file_download_integrity_test.go adds three tests:
- fails by default even when a validator is present (matches the
opt-in policy from 4.8.5)
- resumes correctly when `resume: true` is passed
- fails and cleans up when there's no validator at all
All three fail on the pre-fix code and pass with it.
Note: fileDownloadChunked's unknown-total-size path (used for
YouTube's CDN) has an analogous but harder-to-fix ambiguity - without
a known length there's no way to distinguish a legitimately short
final chunk from a truncated one - left as a follow-up.
Abelardo Ramirez
48dbe3679d