Chrome Returns 206 when the Server Returns 403

In the scenario I propose, 200 is less than the 400 requested, so it's incomplete. The cache is permitted to retain the smaller request, and return bytes that fall exclusively within, but like I said, I don't think it's free return 200 octets when 400 are requested. If it was why would it make the other statements?

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.

No,

(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.

Yeah that's a bad repro. Took me a couple minutes to write a concise one.

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

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

Whether it should or not depends on whether you understand a 403 as a refusal to let you do the given method against the given resource at all, or as a refusal to do this one specific request. The HTTP spec (as I’ve just learned) does support the narrower interpretation if the server wishes it: the description for 403 is just that “[t]he server understood the request, but is refusing to fulfill it”, with no implications regarding other requests for this resource.

> Honestly, this genre of "big tech company refused to fix my very obscure edge case and that confirms all my priors about them" post is getting a little tiresome.

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

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

Yep, reproduced. Caching partial content is a wonderful feature and I’m glad they worked on it. But they clearly shipped some bugs.

Prototypical “bad” technical debt, perhaps.