[mdaniel]

> The Netlog looks scary because it not only contains the traffic while I reproduced the bug but also 1) all traffic from the Chrome plugins and 2) many websites that I have browsed before but haven’t visited during the recording

Isn't that a fantastic use for a 2nd Chrome Profile or even just downloading a Chromium build[1] and using that, showing the behavior in a bleeding edge build?

1: https://download-chromium.appspot.com/

[nightpool]

I was also pretty surprised when the OP said "the Chromium team refused to use my server to reproduce the bug", when the actual comments of the ticket were "clone this repo and run my giant node app" and the tester's response was "It seems a bit difficult to set up an build environment to run the static server, could you provide a more minimal repro case?". OP's description of the tester's reasonable concerns seems very unfair.

Even just having a web-accessible endpoint that reproduced the issue would have made the process a lot smoother I think. Apparently in response to OP's request for an easier test case, OP asked for GCP cloud credits(?) to host their server with?. You probably used more bandwidth & CPU loading the new Chromium issue tracker page then you would have just setting up a simple vps to reproduce the issue

[webdever]

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.

[BalinKing]

I think this is responding to the wrong comment.

[DiggyJohnson]

Yea you are the person you are replying to are in complete agreement.

[oefrha]

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

`go run server.go` and open up http://localhost:8080 in the browser. For Chrome, in the console one should see

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

but if we use "disable cache" this becomes

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

In both Safari and Firefox the second request is 403, cache or not.

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