3 ms·

Chrome's cache is indeed acting correctly. Effectively, it is acting as an intermediary here - your application made a partial content request, and it can satis

by mnot 2y ago

Chrome's cache is indeed acting correctly. Effectively, it is acting as an intermediary here - your application made a partial content request, and it can satisfy it (partially), so it sends you a 206. HTTP partial content responses need to be evaluated (like any other response) according to their metadata: servers are not required to send you exactly the ranges you request, so you need to pay attention to Content-Range and process accordingly (potentially issuing more requests). See: https://httpwg.org/specs/rfc9110.html#status.206 https://httpwg.org/specs/rfc9110.html#status.206

Ajedi32 2y ago
Shouldn't the response header returned by Chrome say "4-138724" then though, and not "4-1943507"? The synthesized response body doesn't include bytes "138725-1943507".
- mnot 2y ago
  Ah - I need to remember to coffee before posting in the AM. Yes, the mismatch between the response headers and the content is a problem. Unfortunately, IME browsers often do "fix ups" of headers that make them less than reliable, this might be one of them -- it's effectively rewriting the response but failing to update all of the metadata. The bug summary says "Chrome returns wrong status code while using range header with caches." That's indeed not a bug. I think the most concerning thing here is that the Content-Range header is obviously incorrect, so Chrome should either be updating it or producing a clear error to alert you -- which it looks like the Chrome dev acknowledges when they say "it is probably a bug that there is no AbortError exception on the read". I might try to add some tests for this to https://cache-tests.fyi/#partial https://cache-tests.fyi/#partial
- yencabulator 2y ago
  Looks like the cache intended to produce those bytes, got the 403 and thus was unable to, and interrupted the stream. Just like a lost connection.
nightpool 2y ago
But the Content-Range header and the Content-Length header both indicated the "expected" number of bytes e.g. the number of bytes that would have been returned if the server had given a 206 or a 200, not the truncated number of bytes that the response actually contained. Is that expected? The latest response from the Chromium team (https://issues.chromium.org/issues/390229583#comment20 https://issues.chromium.org/issues/390229583#comment20) seems to take a different approach from your comment, and says that you should think of it as a streaming response where the connection failed partway through, which feels reasonable to me, except for the fact that `await`ing the response doesn't seem to trigger any errors: https://issues.chromium.org/issues/390229583#comment21 https://issues.chromium.org/issues/390229583#comment21

by mnot 2y ago

Ajedi32 2y ago

Shouldn't the response header returned by Chrome say "4-138724" then though, and not "4-1943507"? The synthesized response body doesn't include bytes "138725-1943507".

mnot 2y ago
Ah - I need to remember to coffee before posting in the AM. Yes, the mismatch between the response headers and the content is a problem. Unfortunately, IME browsers often do "fix ups" of headers that make them less than reliable, this might be one of them -- it's effectively rewriting the response but failing to update all of the metadata. The bug summary says "Chrome returns wrong status code while using range header with caches." That's indeed not a bug. I think the most concerning thing here is that the Content-Range header is obviously incorrect, so Chrome should either be updating it or producing a clear error to alert you -- which it looks like the Chrome dev acknowledges when they say "it is probably a bug that there is no AbortError exception on the read". I might try to add some tests for this to https://cache-tests.fyi/#partial https://cache-tests.fyi/#partial
yencabulator 2y ago
Looks like the cache intended to produce those bytes, got the 403 and thus was unable to, and interrupted the stream. Just like a lost connection.

nightpool 2y ago

But the Content-Range header and the Content-Length header both indicated the "expected" number of bytes e.g. the number of bytes that would have been returned if the server had given a 206 or a 200, not the truncated number of bytes that the response actually contained. Is that expected? The latest response from the Chromium team (https://issues.chromium.org/issues/390229583#comment20 https://issues.chromium.org/issues/390229583#comment20) seems to take a different approach from your comment, and says that you should think of it as a streaming response where the connection failed partway through, which feels reasonable to me, except for the fact that `await`ing the response doesn't seem to trigger any errors: https://issues.chromium.org/issues/390229583#comment21 https://issues.chromium.org/issues/390229583#comment21