Add support for compression dictionary transport

[pmeenan]

Add processing steps for handling HTTP Compression Dictionary Transport content encoding and dictionary negotiation (RFC pending publication).

This adds a processing layer between the HTTP cache and network fetch that handles most of the dictionary-based content encoding (including matching dictionaries to outgoing requests).

Additionally, it adds processing above the HTTP cache for storing the dictionaries for future use and defines the "compression-dictionary" initiator and destination (the matching HTML spec update is in-process).

Support for clearing the caches through clear-site-data is in this PR.

Fix #1739, #1839

• At least two implementers are interested (and none opposed):
  • Chrome
  • Firefox
  • Safari
• Tests are written and can be reviewed and commented upon at:
  • https://github.com/web-platform-tests/wpt/tree/master/fetch/compression-dictionary
  • PR for removal of "tentative": Removed tentative from compression dictionary tests web-platform-tests/wpt#54532
• Implementation bugs are filed:
  • Chromium: https://crbug.com/1413922
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1882979
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=295249
  • Deno (not for CORS changes): Add support for compression dictionary transport denoland/deno#30533
• MDN issue is filed: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Compression_dictionary_transport
• The top of this comment includes a clear commit message to use.

---

Preview | Diff

[pmeenan]

The RFC is pending publication so this will have to wait until that happens (should be any day now). RFC number has been assigned and final edits are complete: https://www.rfc-editor.org/auth48/rfc9842

[pmeenan]

RFC has published now so this should be ready to go (just rebased it).

[pmeenan]

From the TPAC 2025 discussions, I added support for opaque responses to use compression dictionary when the Cross-Origin-Resource-Policy response header is set to cross-origin.

[pmeenan]

Sorry for dragging this out. I think I addressed all of the questions/issues. The main question outstanding right now is if the no-cors path using CORP is "approved" or if there are more steps to getting that integrated before this can land.

I filed it as a question with the TAG but I'm happy do do a more formal review somewhere if necessary.

[pmeenan]

I switched back to only allowing dictionary use for non-opaque requests. It's cleaner from the browser's perspective and harder to get wrong for sites. This is what the browsers have implemented anyway and what the current WPT's test.

The spec change should be ready to go now and match Chrome's and Mozilla's implementations.

If we want to bring dictionary support to third-party embeds in some way (the main pain point for no-cors), we can solve that separately.

[fred-wang]

It seems the text for callers of this algorithm is written that way: "creating a URL pattern, given dictionaryValue["match"], request's current URL and an empty map".

Also, request's current URL is an URL not a string, so we should perform a serialization similar to https://urlpattern.spec.whatwg.org/#other-specs-http (IIUC we can't use that one, because dictionary["match"] is a dictionary value not an HTTP structured field value).

[pmeenan]

Thanks. This should be fixed now. I changed it to extract the "item" from match and to serialize the URL. Let me know if you think a different serialization is needed than the one I used.