Byte-range request
A byte-range request asks an HTTP server to return selected byte intervals of a representation instead of its complete content.
Offsets start at zero and include both endpoints; bytes=0-9 requests ten bytes. Ranges address the encoded representation when content coding is applied. Keep representation identity separate from range coverage and checksum verification.
Relations
Advantages
Limitations
- A server can ignore Range and return 200; do not append that full response as a missing fragment. [1]
- If-Range cannot use a weak ETag; a failed comparison makes the server ignore Range, unlike a failed If-Match precondition. Use an HTTP-date only when no ETag is available and the date qualifies as a strong validator. [1]
- S3 GetObject supports one range per request; use its documented versionId or If-Match controls rather than assuming If-Range support. [2]
- Decompressive transcoding can turn a range request into an entire object transfer; a checksum of the complete stored object does not validate a selected or decoded interval. [4, 5]
- Pinning a stored data generation does not freeze editable metadata; when metadata controls the representation, bind its revision too and check each response's coding before assembly. [5, 6]
Citations
- RFC 9110: If-Range and range requests, sections 13.1.5 and 14
- Amazon S3 API: GetObject, Range, If-Match and versionId
- Google Cloud Storage: gzip transcoding and Range behavior
- Google Cloud Storage XML API: object download and checksum coverage
- Google Cloud Storage: editable metadata, generation and metageneration