The prior --max-filesize 1 aborted on the 301 redirect page's own body
before curl could follow it to the mirror, so the validator reported HTTP
301 for every URL and failed the whole catalog (100+ URLs that are actually
valid). download.kiwix.org 301-redirects both valid and dead files to a
mirror, so the redirect must be followed to learn the real status.
Drop --max-filesize and rely on Range: bytes=0-0 (mirrors return 206 after
one byte) with the body discarded to /dev/null and --max-time as the bound.
Verified against a sample across devdocs/libretexts/stack_exchange/maps/zimit
(all 206) and a known-dead URL (404).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
download.kiwix.org redirects to mirrors, some of which ignore the Range
header and stream the full body, so `curl --max-filesize 1` aborts with exit
63 (CURLE_FILESIZE_EXCEEDED). Under the step's default `bash -eo pipefail`,
that non-zero exit in the `HTTP_CODE=$(...)` assignment killed the whole job
on the first such URL, regardless of the URL being valid. The failure was
non-deterministic (depended which mirror the redirect picked).
Add `|| true` so the assignment can't trip `set -e`; curl still writes the
real %{http_code} (200/206) for the existing check, and a genuine 404 still
returns 404 with exit 0 and is still caught.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Chris Sherwood
Jake Turner
Salman Chishti