I do think the cache is allowed to retain, and respond for the 200 bytes. I don't think it's free to ignore the header updates, nor do I think it's free to return half the requested bytes in lieu of extending the existing cache.

(1) I'm not setting up your server to repo the issue. I have no idea what all that code is going to do. Is it going to try to pown my machine?

(2) No, I'm not going to use your server as a repo. I have no idea you aren't updating it every 5 minutes with a new version.

There's a reason developers ask for an MCVE (Minimal complete verifiable example)

https://www.google.com/search?q=MCVE

It's not unreasonable to ask for one. Sorry if that sucks for you because it's difficult for you pair down your code but that's where we are. Try it on the other side and you'll start to get it.

server.go:

  package main
  
  import (
      "net/http"
  )
  
  func main() {
      http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
          w.Header().Set("Content-Type", "text/html; charset=utf-8")
          w.Write([]byte(`
          <script>
          (async () => {
              await fetch("/test", { headers: { range: "bytes=0-4" } }).then(resp => console.log('bytes=0-4', resp.status));
              await fetch("/test", { headers: { range: "bytes=0-10" } }).then(resp => console.log('bytes=0-10', resp.status));
          })();
          </script>
          `))
      })
      http.HandleFunc("/test", func(w http.ResponseWriter, r *http.Request) {
          w.Header().Set("Access-Control-Allow-Origin", "*")
          w.Header().Set("Content-Type", "text/plain; charset=utf-8")
          switch r.Header.Get("Range") {
          case "bytes=0-4":
              w.Header().Set("Content-Type", "text/plain; charset=utf-8")
              w.Header().Set("Content-Range", "bytes 0-4/1000000")
              w.Header().Set("Last-Modified", "Mon, 03 Mar 2025 00:00:00 GMT")
              w.Header().Set("Etag", "1234567890")
              w.WriteHeader(http.StatusPartialContent)
              w.Write([]byte("01234"))
          case "bytes=0-10":
              w.WriteHeader(http.StatusForbidden)
              w.Write([]byte("Forbidden"))
          default:
              w.WriteHeader(http.StatusBadRequest)
              w.Write([]byte("Bad Request"))
          }
      })
      http.ListenAndServe(":8080", nil)
  }

  bytes=0-4 206
  bytes=0-10 206

  bytes=0-4 206
  GET http://localhost:8080/test 403 (Forbidden)
  bytes=0-10 403

Now, is this surprising? Yes. Does this violate any spec? I'll take Chromium dev's word [1] and say likely not. Should it be "fixed"? Hard to say, but I agree that "fixing" it could break existing things.

[1] https://issues.chromium.org/issues/390229583#comment16

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

Ahh, let's just wait for the startup to fix it then.

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

Prototypical “bad” technical debt, perhaps.