Return a content-encoding header for resource timing and more

[guohuideng2024]

The major change is to add content-encoding to response header list. This PR also adds description on how content-encoding is determined. (content negotiation)

The purpose is to pass such value to resource timing. Further details are available at
w3c/resource-timing#381.

Note: Per discussion at 12/05/2024 webPerWG call (https://docs.google.com/document/d/1mpFDrAWuV6IgvJ1KiL9sgIlcboC5uArtF8r_oqS1Sco/edit?tab=t.0#heading=h.af6v74wysf4m), we decided to allow arbitrary "content-encoding" value at "fetch". We only filter such value at client side, before passing the value to resource timing.

Related PR to modify resource timing specification:
w3c/resource-timing#411

• At least two implementers are interested (and none opposed):
  Likely, Discussed and agreed at Feb 29, 2024 W3C WebPerf call, Chromium already receiving content-encoding through fetch. But not sure about other browsers.

• Tests are written and can be reviewed and commented upon at:
  [to be updated with a new link] https://chromium-review.googlesource.com/c/chromium/src/+/5958411

• Implementation bugs are filed:
  Chromium: https://issues.chromium.org/issues/327941462
  Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1886107
  WebKit: https://bugs.webkit.org/show_bug.cgi?id=271632
  Deno (not for CORS changes): …
  MDN issue is filed:
  New PerformanceResourceTiming.contentEncoding field mdn/content#32823

• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

Bug: w3c/resource-timing#381

---

Preview | Diff

[annevk]

Thanks for taking the time to pick this up. However, it doesn't seem like this addresses all the issues with #1742? I recommend studying the feedback on that PR.

[guohuideng2024]

Thanks for taking the time to pick this up. However, it doesn't seem like this addresses all the issues with #1742? I recommend studying the feedback on that PR.

Hi Anne! I think I should have put up some background information here.

1. You mentioned in Pass in Content-Encoding to resource-timing #1742 that the spec must define how the value is determined. This PR is trying to do that. The value is a result of the "content negotiation" (determine what encoding should be used) so I tried to add that into the existing text.
   Note that Pass in Content-Encoding to resource-timing #1742 is a change similar to one for a previously added field contentType. But contentEncoding is very different, it's not an extracted MIME type, but a result of "content negotiation". So, this PR should be very different from Pass in Content-Encoding to resource-timing #1742

2. We originally thought that the filtering should happen at the "fetch" stage. But in the last web perf meeting Patrick brought up that the returned contentEncoding can be a proprietary value and that value is needed by service worker. So, the unfiltered value must be kept by the browser and the filtering should happen right before reported to resourceTiming.

https://docs.google.com/document/d/1mpFDrAWuV6IgvJ1KiL9sgIlcboC5uArtF8r_oqS1Sco/edit?tab=t.0#heading=h.af6v74wysf4m

Therefore, in this fetch doc I didn't mention filtering. I mentioned "filtering" in the resourceTiming spec:
w3c/resource-timing#411
And I am going to add more details about the filtering there.

Does this sound right to you? I am new to fetch and I may have missed a lot of things here. Thanks for your patience and guidance.
Guohui

[guohuideng2024]

Updated the patch, I just added the content encoding to the body info struct, and add the clause that updates it.

[guohuideng2024]

very sorry for so many mistakes folks. Thanks for you guys' patence.

[noamr]

very sorry for so many mistakes folks. Thanks for you guys' patence.

No worries, we've all been there! (Or at least I have...)

[noamr]

I think this is OK with me, passing on to @annevk. Thanks for addressing the issues!