206 - Partial Content

What Does Partial Content Mean?

A 206 response confirms that the server has successfully processed a "Range Request." Instead of delivering the entire payload, the server provides specific segments (byte ranges). This allows media players to "seek" to any timestamp instantly and enables download managers to resume interrupted transfers without re-downloading existing data. It relies on the "Accept-Ranges" and "Content-Range" headers to coordinate the data reassembly.

Common Causes

• -Large Media Streaming: Modern browsers request video/audio in chunks to allow playback to start before the full file is fetched.
• -Resume Operations: A client resumes an interrupted 2GB download by requesting only the remaining bytes (e.g., Range: bytes=500000-).
• -Multi-threaded Downloading: Tools like IDM opening multiple parallel connections, each requesting a different byte-range to maximize throughput.
• -Cloudfront/CDN Slicing: Intermediate proxies fetching and caching files in "slices" to improve delivery performance for massive assets.

How to Fix Partial Content

1. 1Verify Accept-Ranges: The server must return Accept-Ranges: bytes in the initial 200 OK or HEAD response to signal support.
2. 2Check Content-Range Format: Ensure the response header follows the strict bytes <start>-<end>/<total> format (e.g., bytes 0-1023/5000).
3. 3Enable Range Support in Nginx/Apache: Verify that your web server isn't configured to ignore the Range header or force a 200 OK full-body response.
4. 4Align ETags: Ensure your server cluster generates identical ETags for the same file, as any mismatch will fail a conditional If-Range request.

Step-by-Step Diagnosis for Partial Content

1. 1Test raw range delivery: Run curl -i -H "Range: bytes=0-100" [URL] and confirm the server returns exactly 101 bytes with a 206 status.
2. 2Inspect the "Content-Length" header: In a 206 response, it must reflect the size of the chunk, not the total file size.
3. 3Check for "416 Range Not Satisfiable" errors: This usually means the requested range start is higher than the actual file size (e.g., requesting byte 1001 of a 1000-byte file).
4. 4Verify "If-Range" presence: If the client provides an ETag, confirm the server only sends 206 if the ETag matches current resource state.

curl -v -H "Range: bytes=0-1023" https://errorreference.com/assets/video.mp4
# Look for:
# < HTTP/1.1 206 Partial Content
# < Content-Range: bytes 0-1023/10485760
# < Accept-Ranges: bytes

const getChunk = async (url, start, end) => {
  const response = await fetch(url, {
    headers: { 'Range': `bytes=${start}-${end}` }
  });
  
  if (response.status === 206) {
    const reader = response.body.getReader();
    // Reassemble the byte stream...
  }
};

How to Verify the Fix

• -Establish a partial download: Request Range: bytes=100- and verify the server starts exactly at byte 100.
• -Observe video seeker behavior: Move the playhead in the browser and confirm new 206 requests appear in the Network tab.
• -Check data integrity: Concatenate two 206 chunks and verify the hash (MD5/SHA) matches the same segment of the original file.

How to Prevent Recurrence

• -Avoid Inode-based ETags: In Nginx, use etag on; and avoid using inodes, as different server nodes will produce different ETags for the identical file.
• -Smoke Test Range Logic: Include a test case that requests Range: bytes=0-0 to ensure your backend supports the minimum possible range request.
• -Buffer Management: Ensure your proxy (e.g., Nginx) doesn't buffer the entire file before serving a 206 chunk to a streaming client.
• -Pro-tip: Always include the total file size in the Content-Range header (after the slash) so the client can calculate the total download progress correctly.

Related Errors

Decision Support

Official References

• -MDN Web Docs: HTTP Range Requests
• -Nginx: Efficient Byte-Range Caching
• -RFC 9110 Section 15.3.7 — 206 Partial Content
• -HTTP Official Documentation