HTTP Range Requests & 206 Partial Content Explained
The underlying network mechanism that powers segmented downloading and byte serving.
Under the standard Hypertext Transfer Protocol specifications (RFC 7233), Range Requests allow a client application to request specific subsets of a resource rather than downloading the entire file payload in a single monolithic stream.
1. Discovering Range Support (`Accept-Ranges: bytes`)
Before launching a multi-threaded segmented download, NeXDM issues an initial HEAD or GET probe to inspect server capabilities. If the server supports byte ranges, it includes the following response header:
HTTP/1.1 200 OK Accept-Ranges: bytes Content-Length: 1048576000 Content-Type: application/zip
2. Requesting Byte Slices (`Range: bytes=X-Y`)
Once range support is verified, NeXDM's Rust worker pool partitions the total Content-Length into 64 distinct byte chunks and requests each chunk concurrently across parallel TCP sockets:
GET /file.iso HTTP/1.1 Host: cdn.example.com Range: bytes=0-16383999 GET /file.iso HTTP/1.1 Host: cdn.example.com Range: bytes=16384000-32767999
3. The Server Response: `HTTP 206 Partial Content`
If the range is valid, the server returns status 206 Partial Content with a Content-Range header declaring the byte slice:
HTTP/1.1 206 Partial Content Content-Range: bytes 0-16383999/1048576000 Content-Length: 16384000
4. Assembling Segments on Disk
As each worker thread receives its byte stream, NeXDM uses non-blocking asynchronous file I/O in Rust (via memory-mapped or offset-based file writes) to write each chunk directly into its target disk sector without needing expensive intermediate memory copying or post-download concatenation delays.