For Workers & Pages, what is the name of the domain?
What is the issue or error you’re encountering
R2 range results occasionally off by 64KB
What steps have you taken to resolve the issue?
I have put a workaround in my code to make a cache-busting retry when corrupt data is received.
What are the steps to reproduce the issue?
Media players frequently use range requests to play files in chunks. This bash snippet repeatedly fetches the first 150k bytes of a video file with cache busting and stops if the header is not the expected format. Running it for a while (around 100-400 requests) reliably exits.
for c in {1…1000}; do curl -s -v -H “Range: bytes=0-150000” “https://modr2.ifies.com/25/01/250103_dotty_elf.mp4?attempt=$c&rand=$(head -c 8 /dev/urandom | xxd -p)” | hexdump -C | head -n4 | perl -pe ‘END { exit $status } $status=1 if /isomiso2avc1/;’ && break; done
The expected header looks like:
00000000 00 00 00 20 66 74 79 70 69 73 6f 6d 00 00 02 00 |... ftypisom....|
00000010 69 73 6f 6d 69 73 6f 32 61 76 63 31 6d 70 34 31 |isomiso2avc1mp41|
00000020 00 00 00 08 66 72 65 65 00 52 37 a3 6d 64 61 74 |....free.R7.mdat|
00000030 00 00 02 a1 06 05 ff ff 9d dc 45 e9 bd e6 d9 48 |..........E....H|
< HTTP/2 206
< date: Sat, 22 Feb 2025 22:37:42 GMT
< content-type: video/mp4
< content-length: 150001
< accept-ranges: bytes
< etag: "4dd84009d0b396eaa76db2504f04ec56"
< last-modified: Sat, 04 Jan 2025 05:35:35 GMT
< vary: Accept-Encoding
< content-range: bytes 0-150000/5400054
< cache-control: max-age=14400
< cf-cache-status: MISS
< report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v4?s=5KtC4XBzDUK1bIb9bcPa%2B0pqOEF1hhkXucMM5mFmetAUp9ULu4yNSmAQ3Ciy7BUTqj2CIvAc7MVH1VI8VpNXlVzmYacbhuKuhcXiGUKZ2Ii%2BqccZMxRCRwZvPDKLtG1QNjc%3D"}],"group":"cf-nel","max_age":604800}
< nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
< server: cloudflare
< cf-ray: 916276565c20e672-DEN
< alt-svc: h3=":443"; ma=86400
< server-timing: cfL4;desc="?proto=TCP&rtt=14272&min_rtt=13447&rtt_var=3765&sent=7&recv=9&lost=0&retrans=0&sent_bytes=3427&recv_bytes=813&delivery_rate=182436&cwnd=252&unsent_bytes=0&cid=eccce8e661b29680&ts=147&x=0"
<
{ [1360 bytes data]
00000000 ba 20 8a 0f 1a 01 9f 83 da f5 5f a7 37 c4 40 82 |. ........_.7.@.|
00000010 f1 a8 32 68 6a 2d ee 9f c8 48 6b 64 52 b0 48 1f |..2hj-...HkdR.H.|
00000020 a7 47 b6 da 94 cc f8 e2 56 4b ce 89 97 94 51 18 |.G......VK....Q.|
00000030 de 3a e8 6f 25 7a 68 f8 df cf a3 e1 07 50 d5 a9 |.:.o%zh......P..|
Note that the response headers don’t indicate any errors. Curiously, this data isn’t a random corruption! It is exactly 64KB (0x10000) into the file:
$ curl -s https://modr2.ifies.com/25/01/250103_dotty_elf.mp4 | hexdump -C | grep 'ba 20 8a 0f 1a'
00010000 ba 20 8a 0f 1a 01 9f 83 da f5 5f a7 37 c4 40 82 |. ........_.7.@.|
The failure rate appears to be somewhere from 0.1%-0.5% of requests of this form.
Range requests that don’t start from 0 do not appear to fail in the same way. Range requests for under ~40KB of data do not appear to fail in the same way.