Your video breaks when you serve it from your own server, and 416 is usually the reason

When you serve private files from your own server instead of using presigned URLs, video files often fail to load properly. The issue arises when the player loads but the timeline remains dead and scrubbing does nothing. Logs don't show any errors because the server treats every request as a 200. The root cause is the Range header and how it interacts with object stores like S3 or R2.

When redirecting to a presigned URL, the object store handles range requests efficiently. However, when you proxy the request, it becomes your code's responsibility, including parts unrelated to your application. A video player, for example, sends a range request before allowing user scrubbing. A PDF reader typically asks for the last few bytes first, as the cross-reference table is at the end of the file.

If the server responds with a 416 Range Not Satisfiable, it indicates the range cannot be served as requested, but RFC 9110 suggests ignoring the invalid range instead of refusing it.

Correctly handling ranges is crucial. A range that parses cleanly but cannot be satisfied due to object size should result in a 200 response containing the entire object, rather than a 416. Misinterpreting this can lead to data corruption issues, where the client assumes the 206 response covers only the first range and incorrectly stitches in the second range. Properly handling these cases ensures the file remains intact and behaves as intended.