https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#rfc.section.9.3
If all of the preconditions are true, the server supports the Range header field for the target resource, and the specified range(s) are valid and satisfiable (as defined in Section 7.1.4.2), the server SHOULD send a 206 (Partial Content) response with a payload containing one or more partial representations that correspond to the satisfiable ranges requested.
This seems to place a requirement on the server to serve enough of the representation that all satisfiable ranges requested are fulfilled.
But that's actually a burden and makes range requests not as useful as they could be: a server might well not want to implement multipart/byteranges, which is an awkward format that can't be streamed without prior knowledge of what strings are safe to use as separators; responding with a single range is much simpler to implement.
If all satisfiable ranges must be served, then, without multipart/byteranges, the only compliant options for responding to a range request with large distances between the requested ranges involve sending all of the bytes in between.
Even reading the text as meaning that servers MUST NOT only serve a portion of the satisfiable ranges, client behaviour when faced with a misbehaving server is under-specified; the sensible options are re-requesting unfulfilled ranges, retrying without ranges, or signalling an error. Retrying without ranges may be wasteful, and raising an error seems overly fussy - and, if either of those is the better or even necessary option, that definitely ought to be called out. I'd be surprised if retrying without ranges or erroring was needed, because section 10.3.7.3 (Combining Parts) already deals with combining multiple 206 responses together.
So, I think it'd make sense to make two changes here:
- An explicit SHOULD on clients receiving a 206 to check the ranges that they actually received and make further range requests if they still need any ranges which weren't included despite being satisfiable, which they can determine because Content-Range includes enough information to tell which were unsatisfiable and which were simply not fulfilled.
- Explicitly say that servers MAY only serve a portion of the satisfiable ranges.
https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#rfc.section.9.3
This seems to place a requirement on the server to serve enough of the representation that all satisfiable ranges requested are fulfilled.
But that's actually a burden and makes range requests not as useful as they could be: a server might well not want to implement multipart/byteranges, which is an awkward format that can't be streamed without prior knowledge of what strings are safe to use as separators; responding with a single range is much simpler to implement.
If all satisfiable ranges must be served, then, without multipart/byteranges, the only compliant options for responding to a range request with large distances between the requested ranges involve sending all of the bytes in between.
Even reading the text as meaning that servers MUST NOT only serve a portion of the satisfiable ranges, client behaviour when faced with a misbehaving server is under-specified; the sensible options are re-requesting unfulfilled ranges, retrying without ranges, or signalling an error. Retrying without ranges may be wasteful, and raising an error seems overly fussy - and, if either of those is the better or even necessary option, that definitely ought to be called out. I'd be surprised if retrying without ranges or erroring was needed, because section 10.3.7.3 (Combining Parts) already deals with combining multiple 206 responses together.
So, I think it'd make sense to make two changes here: