The actual issue is more involved: Chrome wrongly returns 206 Partial Content upon a range request when it already had part of the range in its cache (due to a previous request that correctly returned a 206) and Chrome's attempt to get the remaining part yielded a 403. The Chrome team suggests, citing unspecified compatibility concerns, for the client code to notice that (from its point of view) either Chrome or the web server violated the range request contract by returning less than what was requested and to then rerequest the remaining part as a separate range, which will, finally, return a 403. That makes no sense to me, but what do I know.
The spec for HTTP GET is of course in no way similar to the spec for read(). On the other hand, I have to concede that (as I’ve just learned) an HTTP server is actually within its rights[1] to return only part of the requested range(s) and expect the client to redo the request if it needs the rest:
> A server that supports range requests (Section 14) will usually attempt to satisfy all of the requested ranges, since sending less data will likely result in another client request for the remainder. However, a server might want to send only a subset of the data requested for reasons of its own, such as temporary unavailability, cache efficiency, load balancing, etc. Since a 206 response is self-descriptive, the client can still understand a response that only partially satisfies its range request.
The only thing I'd note is that the spec seems to be pretty clear about the content-length response header needing to match how many bytes are actually in the response, and the 206 from Chrome is not returning a number of bytes matching the content-length header. Spec:
> A Content-Length header field present in a 206 response indicates the number of octets in the content of this message, which is usually not the complete length of the selected representation.
While in the article (and in the mailing group discussion) it seems that Chrome is responding with a `content-length` of 1943504 while the body of the response only contains 138721 octets. Unless there's some even more obscure part of the spec, that definitely seems like a bug as it makes detecting the need to re-request more annoying.
Having taken a minute to understand this, I agree with the chrome team - it's not a bug, but rather an unfortunate complexity of interacting with caching and a server. It's definitely a choice on their part to issue a request different than the one you asked for by partially satisfying it from cache and asking the server for the rest. But it's not an unseasonable optimization. At which point when their shorter range request fails, they have no way to message the 403 back to you and also give back the partial content. So they chose to pass back the partial content.
I think it's a bit more complicated. Returning partial content seems to be a valid response according to the spec. But the Content-Range and Content-Length headers shown in Chrome DevTools are clearly wrong, they should indicate what is actually returned. So I still think there's a small bug in how Chrome handles this, but solving this bug wouldn't help the author, as it's still the responsibility of OpenDAL to fix handling partial content on their side.
This seems like a better design than returning no data and a 403, and they wouldn't be the first people to run into it and have to properly handle a partial range response.
