Aug 15

Uploaded video files not served with HTTP Range support (breaks <video> in Safari / all iOS browsers)

**Summary** : Videos uploaded to [umsousercontent.com](http://umsousercontent.com) are served with HTTP 200 and no Accept-Ranges/Content-Range, even for Range requests. WebKit (Safari on macOS, and all browsers on iOS) requires 206 Partial Content to play a \<video\>, so recently uploaded videos fail to play there. Chrome/Firefox on desktop tolerate 200, so it's easy to miss. Impact: Any \<video\> using a freshly uploaded file is broken for every Safari and iOS visitor. **Reproduce** : # Recent upload — returns 200, no range headers (broken in Safari/iOS): curl -s -o /dev/null -D - -H 'Range: bytes=0-1' \ 'https://umsousercontent.com/lib_hvWHwWxTEIwhsiou/kt2mbust45y…' \ | grep -iE 'HTTP/|accept-ranges|content-range' # HTTP/2 200 # An older file in the same library — correctly returns 206 (plays fine): curl -s -o /dev/null -D - -H 'Range: bytes=0-1' \ 'https://umsousercontent.com/lib_hvWHwWxTEIwhsiou/dzrfko3rddp…' \ | grep -iE 'HTTP/|accept-ranges|content-range' # HTTP/2 206 # content-range: bytes 0-1/2561489 **Notes** : - Same library, same file type — the only difference is that the older file gets 206. New uploads (tested multiple) consistently get 200. Re-uploading did not fix it. - The 200 responses carry cache-control: public, max-age=31536000, immutable, so a non-range-capable cache entry appears to get pinned for a long time. **Expected** : Video assets should be served with Accept-Ranges: bytes and honor Range requests (206), as the older file does. **Workaround in use** : Hosting the file elsewhere (CloudFront-backed) that serves 206.

Completed