[mnot]

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

[nightpool]

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) 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

[Ajedi32]

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]

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

[yencabulator]

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.