Range requests are how a client asks for a specific slice of a resource. The server can answer with 206 Partial Content and the requested bytes, ignore the header and send the whole file with 200 OK, or reject an invalid range with 416 Range Not Satisfiable.
FAST-VID delivers completed media files with byte-range support, but that does not make every download resumable at every stage. Source extraction, temporary links, changing files and network intermediaries can all change the result.
What a Range request asks for
The client sends a Range header such as Range: bytes=0-499. That means the first 500 bytes, because both ends are inclusive in the request syntax. A suffix form such as bytes=-500 requests the last 500 bytes. An open-ended form such as bytes=500- requests from byte 500 to the end.
A server that supports ranges can reply with 206 Partial Content. The response includes Content-Range, for example bytes 0-499/10000, and the response body contains only those bytes. The total file size appears after the slash.
If the server does not support ranges or chooses to ignore the request, it can send 200 OK with the complete representation. A client must not assume that a 206 is guaranteed just because it sent a Range header.
The status codes and headers that matter
Accept-Ranges: bytes advertises that the server accepts byte ranges for the resource. It is a hint about capability, not a promise that every specific range will succeed.
Content-Range identifies the byte interval in a partial response and the complete length. A mismatch between the requested interval and the returned interval is a reason to stop and restart rather than append bytes blindly.
206 Partial Content means the response is a partial representation. 200 OK can mean the server ignored the range and is sending the whole file. 416 Range Not Satisfiable means the requested range cannot be satisfied, often because the start is past the end or the syntax is invalid. A 416 response often includes Content-Range: bytes */size.
The If-Range header helps a client avoid combining bytes from different versions. If the validator no longer matches, the server can send the full representation instead of a partial one.
| Result | Meaning | Client action |
|---|---|---|
| 206 with Content-Range | Requested bytes returned | Verify interval, then append |
| 200 full file | Range ignored or unsupported | Restart or accept a full download |
| 416 | Range invalid or unsatisfiable | Restart from a valid position |
| Accept-Ranges: bytes | Byte ranges advertised | Attempt a range, but verify the response |
How resuming works in practice
A download manager records how many bytes it has written. After an interruption, it asks for the next range, for example bytes=1048576-, and appends only when the server returns the expected 206 and matching Content-Range. The final file must be assembled in the same order and must match the original representation.
Resume depends on the resource being stable. If the file changed between attempts, the old bytes may belong to a different version. Validators such as an ETag or Last-Modified value, together with If-Range, help avoid a corrupt mix. A server can also use a different content encoding or transfer behavior on a later request.
A browser download and a resumable protocol are not the same feature. The browser may retry, but a server that returns 200 to every request forces a fresh transfer. Some download managers are better at preserving partial state than a browser's normal download flow.
Why Range support can fail
Range handling is optional. A server may ignore the header, a proxy or cache may normalize the request, or an application may generate the response dynamically and not support ranges. Authentication, signed URLs and short-lived tokens can also expire between attempts.
A cache can serve a complete object even when the origin supports ranges, or can have a partial object with different validators. A compression layer can interfere with byte offsets if it changes the representation; media responses should avoid transformations that break range semantics.
If the URL points to a live stream, a manifest or a changing resource, byte ranges may not map to a stable downloadable file at all. A range request is a tool for a stable representation, not a universal resume command.
What FAST-VID verifies and what it does not
For completed media files, FAST-VID's file response advertises Accept-Ranges: bytes, returns 206 for a valid single range, returns 416 for an invalid or multiple range, supports HEAD, and sets Content-Range on partial responses. The deployment configuration also bypasses compression for the media file route so byte ranges and content length are not altered by compression.
Synthetic Caddy media tests cover 206, invalid-range 416, HEAD requests and compression bypass. These tests verify the delivery path for a completed media file; they do not prove that every source, browser, network or interrupted job can resume.
FAST-VID does not promise universal resume support across all servers, source URLs or browsers, and it does not claim that an interrupted source-media extraction job can resume from its previous position. Browser-to-FAST-VID delivery and worker-to-source extraction are separate paths.
Troubleshooting a download that will not resume
Check whether the response is 206 or 200. A 200 means the range was ignored or the file is being sent in full. Check Content-Range against the expected interval and total size. A 416 usually means the requested start is invalid or the file changed.
If a signed link expired, request a new link rather than modifying the URL. If a proxy or cache is involved, compare behavior on another network. Do not append bytes from a response that lacks a matching range or validator.
When in doubt, restart the download and keep the completed file until it is verified. A corrupt resumed file is worse than a slower clean transfer.
Frequently asked questions
What does a Range request do?
It asks the server to send only a specified byte interval of a resource. The server may return 206 Partial Content, ignore the request with 200 OK, or reject an invalid range with 416.
Does 206 always mean the download can resume?
No. The response must match the requested range and the resource must be stable. A later request can still fail, expire or return the full file.
What does Accept-Ranges: bytes mean?
It advertises that the server accepts byte ranges for that resource. It does not guarantee that every range request will succeed.
Why did I get 200 instead of 206?
The server may not support ranges, may choose to ignore the header, or a proxy/cache may return the complete representation.
Can FAST-VID resume every interrupted job?
No. FAST-VID supports ranges when delivering completed media files, but it does not guarantee resume for every source, browser or interrupted extraction job.
Sources and references
- IETF RFC 9110: HTTP Semantics
- MDN: Range header
- MDN: Content-Range header
- MDN: Accept-Ranges header
- MDN: 206 Partial Content
- MDN: 416 Range Not Satisfiable
- FAST-VID: Downloaded video corrupted or not playing
Try FAST-VID
Open the FAST-VID downloader for a supported public link. Range support helps with completed-file delivery; it does not guarantee resume for every source or network.