-
Notifications
You must be signed in to change notification settings - Fork 37
object-store: http shouldn't perform range requests unless accept-ranges: bytes
header is present
#134
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
The RFC would suggest this is not a requirement - https://www.rfc-editor.org/rfc/rfc9110#section-14.3 Potentially we should instead be checking for a 206 response and returning an error if we get back a 200 🤔. I definitely think we should return an error if a range request is requested but ignored, as falling back to fetching the entire file is almost never desirable. |
Hmm. If we'd error on a 200, wouldn't we have still performed the full request at that point though? ... But i guess there's no good way to actually know if a server supports it without actually trying to perform the request. |
We will have read the response headers but not streamed the majority of the request body. I'm not sure what hyper does if you simply discard the response body. Regardless I view this as being an exceptional case not worth overly optimising for, as I anticipate most workloads will simply treat it as fatal error and abort the query/task |
|
Migrating from arrow-rs issue #4839 |
Describe the bug
if you have a remote file
https://somewhere.com/file.parquet
and your server does not support ranges as specified by theaccept-ranges: bytes
header, the object store should not try to perform range scans.To Reproduce
Expected behavior
the range is ignored as the server doesn't specify it can handle it.
Additional context
The text was updated successfully, but these errors were encountered: