You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: Initial support for HTTP range requests (#481)
Adds standard HTTP [range
requests](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Range_requests)
([RFC](https://www.rfc-editor.org/rfc/rfc9110.html#name-range-requests))
support for single-object GET operations.
Spec vs implementation:
- This implementation only supports byte ranges. The spec doesn't
specifically talk about bytes, so in theory it admits ranges of other
"types", which just don't make sense for us.
- This implementation only supports [Single part
ranges](https://developer.mozilla.org/enUS/docs/Web/HTTP/Guides/Range_requests#single_part_ranges),
meaning stuff like `Range: bytes=0-1023`. The spec allows for [Multipart
ranges](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Range_requests#multipart_ranges)
too, i.e. fetching multiple ranges in a single request, which we don't
support. We can add it in the future if needed.
- We should probably implement [Conditional range
requests](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Range_requests#conditional_range_requests)
in a follow-up PR, as they're pretty much essential to guarantee that
clients read consistent data (if the object is swapped between range
reads, we would otherwise serve chunks from 2 potentially different
objects). Note that Symbolicator doesn't use these, so we should also
update Symbolicator and any other user that uses range reads to actually
use these to prevent random failures/data inconsistency. (maybe in
practice this is fine as data that Symbolicator fetches cannot really
change due to the way it's written, I don't know yet)
**Looking for feedback on whether we think we need this now or not**.
Implementation details:
- All `get_object` paths now take `Option<ByteRange>` and return
`ContentRange` alongside the payload. This seems to be the way to
implement this with the least code duplication. Otherwise we would have
to introduce a `get_object_range`, implement it for every backend and
wrappers of the backends, etc.
- Bigtable: we know that the objects there are small, so we just return
the full payload. This behavior is compliant with the spec.
- GCS/S3: `objectstore-service` reserializes the `Range` header and
forwards it to the backend. On the response path, we proxy back the
`content-range` provided by the backend. TODO:
- Not supported for batch operations.
- Not implemented in clients for now because Symbolicator (which would
be the only user atm) doesn't use our client. We can easily implement it
when needed.
Close FS-363
0 commit comments