3 ms·

Chrome gives you what data it has, and you are expected to issue the next request to get the rest of the data. Consider a read() call in Linux if you ask to r

by ayende 2y ago

Chrome gives you what data it has, and you are expected to issue the next request to get the rest of the data. Consider a read() call in Linux if you ask to read 16kb and the cache has 4kb page ready, it may give you that. You'll need another call to get the rest, and if there is a bad disk sector, that first read() may bot notice that

mlhpdx 2y ago
I’m not sure I follow. The second request is for an overlapping range and can’t be satisfied because of the 403. There’s just no way around that.
mananaysiempre 2y ago
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. [1] https://www.rfc-editor.org/rfc/rfc9110.html#name-206-partial-content https://www.rfc-editor.org/rfc/rfc9110.html#name-206-partial...
- lelandbatey 2y ago
  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.
  - deleted 2y ago
    [deleted]

by ayende 2y ago

mlhpdx 2y ago

I’m not sure I follow. The second request is for an overlapping range and can’t be satisfied because of the 403. There’s just no way around that.

mananaysiempre 2y ago

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. [1] https://www.rfc-editor.org/rfc/rfc9110.html#name-206-partial-content https://www.rfc-editor.org/rfc/rfc9110.html#name-206-partial...

lelandbatey 2y ago
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.
- deleted 2y ago
  [deleted]