Added support for link rel=compression-dictionary by pmeenan · Pull Request #11620 · whatwg/html

pmeenan · 2025-09-03T19:14:59Z

Add processing steps for handling the "compression-dictionary" link relation type defined in HTTP Compression Dictionary Transport.

It largely mirrors the support for prefetch but also adds a default crossorigin mode of "cors" anonymous (necessary for dictionaries to be usable in a third-party context).

Fix #11619

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
Corresponding HTML AAM & ARIA in HTML issues & PRs:
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.

/index.html ( diff )
/links.html ( diff )
/references.html ( diff )
/semantics.html ( diff )

pmeenan · 2025-09-03T19:15:42Z

RFC is pending publication so this should wait until it has been published (any day now - final edits are complete).

domenic · 2025-09-04T04:35:26Z

+  </ol>
+
+  <p>The <span>process a link header</span> steps for this type of linked resource are to do
+  nothing.</p>


Double-checking that this is intended? https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/ seems to imply the Link: header should work, but this mandates that in browsers it do nothing.

Thanks. Mistake from mirroring the prefetch behavior. Should be fixed now. The flow feels a bit weird since I merged the header and link element processing steps but need to not fire the load/error in the header side of things (made el optional to the processing). Happy for suggestions on ways to make it cleaner.

Presumably we could also treat it more like preconnect and fire-and-forget without load/error events.

I think the intended pattern is supposed to be like what preload does. I believe you could make that work, but I haven't double-checked...

domenic · 2025-09-04T04:40:23Z

The structure here is a bit surprising for me, in that you have HTML just do a fetch, and then do nothing with the response.

Instead, you seem to have located the response processing all in whatwg/fetch#1854. I can understand that if the goal is that there are many places that should be able to trigger that processing, e.g., if you want to be able to trigger it from fetch(). But, if HTML is the only place on the web platform that can set a "compression-dictionary" initiator, what is the point of that?

A more normal processing model would be to process the response in HTML, and not modify Fetch much. Was that considered?

pmeenan · 2025-09-04T16:40:22Z

The structure here is a bit surprising for me, in that you have HTML just do a fetch, and then do nothing with the response.

Instead, you seem to have located the response processing all in whatwg/fetch#1854. I can understand that if the goal is that there are many places that should be able to trigger that processing, e.g., if you want to be able to trigger it from fetch(). But, if HTML is the only place on the web platform that can set a "compression-dictionary" initiator, what is the point of that?

A more normal processing model would be to process the response in HTML, and not modify Fetch much. Was that considered?

Compression dictionaries are a transport-layer content-encoding and entirely handled within fetch. For the most part they should be completely transparent to HTML. Any HTTP response for any fetch can be stored as a compression dictionary and, usually, none of that will even be visible from HTML.

We did need a way to trigger a fetch for triggering the request of a dictionary that would not have otherwise been loaded (which will then be treated like any other response and handled entirely at the HTTP layer). preload and prefetch both would have worked fine (and can still work if someone uses them and they have the appropriate response headers) but by using a dedicated relation type we can avoid triggering fetches from clients that don't support compression dictionaries.

It also allows for adjusting the priorities and timing of the fetch independently from prefetches and preloads.

domenic · 2025-09-08T07:07:39Z

Any HTTP response for any fetch can be stored as a compression dictionary and, usually, none of that will even be visible from HTML.

Got it. I misunderstood the role of the compression-dictionary initiator. It is not required that the request initiator be set to compression-dictionary, for the response to be used as such.

In that case, I agree with the design split.

pmeenan · 2025-11-11T16:49:33Z

The RFC finally published so this should be ready for review now (just rebased it).

domfarolino · 2025-11-18T17:38:24Z

+  that preemptively <span data-x="concept-fetch">fetching</span> and caching the specified resource
+  or same-site document is likely to be beneficial, as it is highly likely that the user will
+  be able to this resource as a compression dictionary for future
+  <span data-x="concept-fetch">fetches</span>. <ref>RFC9842</ref></p>


Is this ref required? We're not referencing any definition from that spec, right? (Maybe I don't understand all the ref rules and Anne can correct me).

There are 2 <ref>RFC9842</ref> references in the PR (both around similar language for link) and they are the only references to the compression dictionary RFC. I'm fine with removing both of them but then people would likely have to go through the fetch spec and from there to the RFC to see what compression dictionaries are.

The closest analog I could see in the code is from the img src text when it references the various bitmap formats without explicitly relying on anything in their specifications (around line 30710):

<p class="note">The requirements above imply that images can be static bitmaps (e.g. PNGs, GIFs, JPEGs), single-page vector documents (single-page PDFs, XML files with an SVG document element), animated bitmaps (APNGs, animated GIFs), animated vector graphics (XML files with an SVG <span>document element</span> that use declarative SMIL animation), and so forth. However, these definitions preclude SVG files with script, multipage PDF files, interactive MNG files, HTML documents, plain text documents, and the like. <ref>PNG</ref> <ref>GIF</ref> <ref>JPEG</ref> <ref>PDF</ref> <ref>XML</ref> <ref>APNG</ref> <ref>SVG</ref> <ref>MNG</ref></p>

domfarolino · 2025-11-18T18:01:43Z

+  data-x="create link options from element">create link options</span> from <var>el</var> and
+  to <span>load a compression dictionary</span> given the result and <var>el</var>.</p>
+
+  <p>The <span>process a link header</span> step for this type of linked resource given a <span


My understanding from TPAC is that compression dictionary responses are intended to be processed almost primarily on subresource requests. But this header-processing algorithm does not run in those cases, and in fact we do not have a spec'ed processing model for subresource Link header requests. Is my understanding correct, and do we have tests for this behavior?

We haven't really had a pressing need to spec the Link header processing model on subresource requests, but if that's one of the main and expected ways of engaging with this new feature, and we have tests for it, perhaps it's important enough to invest in.

The Link header is independent from the use of the dictionaries for compression and is used to trigger the loading of a stand-alone dictionary (instead of the subresource delta-compression model where a response is a dictionary itself).

The main use case envisioned is for a HTML document to trigger the loading of a dictionary that would be used in future document requests (compressing away the common HTML templates).

That said, I am sure someone would have a use case for triggering a separate dictionary request from subresources and that might be something Chrome currently allows (along with preload and preconnect) though there are ongoing discussions about how those should be handled to avoid tracking concerns.

The dictionary use case for subresource link headers should probably be included in whatever spec work we do to specify the behavior for preconnect and preload.

Right now the only WPT tests that use the Link header are for the document itself.

See #11619 (comment) and web-platform-tests/wpt#61229

fred-wang · 2026-06-09T10:03:25Z

+  <p>The <code data-x="rel-compression-dictionary">compression-dictionary</code> keyword indicates
+  that preemptively <span data-x="concept-fetch">fetching</span> and caching the specified resource
+  or same-site document is likely to be beneficial, as it is highly likely that the user will
+  be able to this resource as a compression dictionary for future


"the user will be able to this resource" => I think some verb is missing here?

fred-wang · 2026-06-09T10:19:17Z

+  <code data-x="rel-compression-dictionary">compression-dictionary</code> keyword.</p>
+
+  <p>The appropriate times to <span data-x="fetch and process the linked resource">fetch and
+  process</span> this type of link are:</p>


AFAIK, we only have one test fetch/compression-dictionary/dictionary-fetch-with-link-element.tentative.https.html for <link rel=compression-dictionary> and it only covers a simple case: a link element is created, inserted it in the doc and we check that the dictionary becomes available at some point in the future.

We should also tests that dictionary does not become available after some timeout if not all conditions are fulfilled (e.g. that if we create a link but without inserting it in the document).

It would also be interesting to check load cancellation or update (e.g. the attribute href attribute is removed or modified before the fetch started) but I suspect that will require a way to be sure a load hasn't started.

We should also tests that dictionary does not become available after some timeout if not all conditions are fulfilled (e.g. that if we create a link but without inserting it in the document).

"no more dictionary fetched" from https://github.com/web-platform-tests/wpt/blob/master/fetch/compression-dictionary/dictionary-fetch-timing-002.tentative.https.html should cover that.

It would also be interesting to check load cancellation or update (e.g. the attribute href attribute is removed or modified before the fetch started) but I suspect that will require a way to be sure a load hasn't started.

I guess the timing will be complicated and result in flaky test, so probably not worth doing.

fred-wang · 2026-06-09T10:22:59Z

+
+  <ul>
+   <li><p>When the <span>external resource link</span> is created on a <code>link</code> element
+   that is already <span>browsing-context connected</span>.</p></li>


Does that correspond to a <link rel="compression-dictionary"> that is already present in the doc (not dynamically inserted)? If so it does not seem to be covered by the tests.

This is covered by https://github.com/web-platform-tests/wpt/blob/master/fetch/compression-dictionary/dictionary-fetch-timing-002.tentative.https.html now (alreadyBrowsingContextConnected)

fred-wang · 2026-06-09T10:24:06Z

+   that is already <span>browsing-context connected</span>.</p></li>
+
+   <li><p>When the <span>external resource link</span>'s <code>link</code> element <span>becomes
+   browsing-context connected</span>.</p></li>


This is the case covered by the test, but maybe we should also check that, before the insertion, dictionary does not become available.

https://github.com/web-platform-tests/wpt/blob/master/fetch/compression-dictionary/dictionary-fetch-timing-002.tentative.https.html also checks that no fetch happens before the link is browsing-context conntected (linkDynamicallyBrowsingContextConnected and "no more dictionary fetched")

fred-wang · 2026-06-09T10:24:53Z

+
+   <li><p>When the <code data-x="attr-link-href">href</code> attribute of the <code>link</code>
+   element of an <span>external resource link</span> that is already <span>browsing-context
+   connected</span> is changed.</p></li>


This does not seem to be covered by existing tests.

https://github.com/web-platform-tests/wpt/blob/master/fetch/compression-dictionary/dictionary-fetch-timing-002.tentative.https.html covers this now (hrefDynamicallySet, hrefDynamicallyRemoved, hrefDynamicallyChanged)

fred-wang · 2026-06-09T10:50:47Z

+  <div algorithm>
+  <p>The <span>fetch and process the linked resource</span> steps for this type of linked resource,
+  given a <code>link</code> element <var>el</var>, are to <span
+  data-x="create link options from element">create link options</span> from <var>el</var> and


So I guess there is a bunch of options to be tested here: https://html.spec.whatwg.org/#create-link-options-from-element ; dictionary-fetch-with-link-element.tentative.https.html seems quite limited with only a test for crossorigin=anonymous (which is also default).

Chromium does not seem to pass down the nonce attribute down to the fetch algorithm. I tried a WPT test and a patch here, but I'm not quite sure it's correct: https://chromium-review.googlesource.com/c/chromium/src/+/8098863

OK, I went over https://html.spec.whatwg.org/multipage/semantics.html#create-link-options-from-element and I think we have some satisfying coverage here:

crossorigin: https://chromium-review.googlesource.com/c/chromium/src/+/8098207
referrer policy: https://chromium-review.googlesource.com/c/chromium/src/+/8118407
source set: Not exposed by https://fetch.spec.whatwg.org/#request-class, this only seems to be used for rel=preload and destination=image, added a tentative test at https://chromium-review.googlesource.com/c/chromium/src/+/8124456
baseURL: Added https://chromium-review.googlesource.com/c/chromium/src/+/8117615
origin: Not exposed by https://fetch.spec.whatwg.org/#request-class, this only seems to be used for rel=preconnect
environment: Relevant usage seems to be to use request's client https://html.spec.whatwg.org/multipage/semantics.html#fetching-and-processing-a-resource-from-a-link-element:link-options-environment which is used for many things in the fetch spec, including checking that compression-dictionary don't work in insecure context (test dictionary-insecure-context.tentative.http.html).
policy container: Likely covered by any tests involving policies, e.g. web-platform-tests/wpt#61309
document: This only seems to be used by rel=preload
cryptographic nonce metadata: Not exposed by https://fetch.spec.whatwg.org/#request-class, attribute should not affect CSP, tentative test at https://chromium-review.googlesource.com/c/chromium/src/+/8098863
fetch priority: Not exposed by https://fetch.spec.whatwg.org/#request-class, attribute can affect server-side prioritization of requests, but that's implementation-defined and so we can't have a shared WPT.
href: Covered by any test registering the dictionary, there are many of them!
integrity: Attribute is not accepted and shouldn't be transmitted to the fetch, tentative test at https://chromium-review.googlesource.com/c/chromium/src/+/8117450
type: Not exposed by https://fetch.spec.whatwg.org/#request-class, type attribute is somehow tested in web-platform-tests/wpt#61211 ; the link option does not seem to be used for rel=compression-dictionary.

fred-wang · 2026-06-09T10:53:20Z

+
+  <p>The <span>process a link header</span> step for this type of linked resource given a <span
+  data-x="link processing options">link processing options</span> <var>options</var> are to
+  <span>load a compression dictionary</span> given <var>options</var>.</p>


Same here, I don't see a lot of options tested for dictionary-fetch-with-link-header.tentative.https.html

As commented above I added several tests for options, although often it's only for the link element only, for which one can configure things via attributes. We could add similar tests for link header.

fred-wang · 2026-06-09T10:59:31Z

+     data-x="event-error">error</code> at <var>el</var>.</p></li>
+
+     <li><p>Otherwise, if <var>el</var> is set, <span data-x="concept-event-fire">fire an event</span>
+     named <code data-x="event-load">load</code> at <var>el</var>.</p></li>


Can we please add WPT tests for these two events? (for both Link header and element).

Tentative test at https://chromium-review.googlesource.com/c/chromium/src/+/8036725

for Link header, I'm unsure there is reasonable way to check the load/error are not dispatched, since we don't have link anyway...

fred-wang · 2026-06-09T11:19:21Z

+   <li><p>The user agent should <span data-x="concept-fetch">fetch</span> <var>request</var>, with
+   <i data-x="processResponseConsumeBody">processResponseConsumeBody</i> set to
+   <var>processCompressionDictionaryResponse</var>. User agents may delay the fetching of
+   <var>request</var> to prioritize other requests that are necessary for the current document.</p></li>


I understand this is based on "prefetch", but I believe the spec should clarify the timing for <link rel=compression-dictionary>.

From whatwg/fetch#1854 (comment) I understand we need to wait a browser's idle period (which I guess can be verified with https://developer.mozilla.org/en-US/docs/Web/API/Window/requestIdleCallback for browsers that support it, or otherwise a double requestAnimationFrame) and (maybe) until the document load event was already dispatched.

Again, it would be nice to have some tests that verify we don't trigger the load before these conditions are met. Perhaps the events from the previous sections would be useful for that purpose.

Regarding Link header, I understand these conditions do not apply. I suspect we'd prefer to handle preconnect and preload before, but https://html.spec.whatwg.org/#process-link-headers does not seem to indicate a preferred order.

@pmeenan shared info privately based on Chromium's code, basically:

For Link header handling of compressed-dictionary is deferred after the document load completes.

For Link element, this is done asap as described here (when browsing-context connected etc).

For both Link header and element, this is done by pushing the fetches into a task queue, which are executed only when the browser's main thread becomes idle.

In one comment above, the case of subresources was mentioned. It seems Chromium handles them a bit differently, as Link header for them is allowed before the load completes when they are not coming from the memory cache: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/loader/preload_helper.cc;l=252;drc=88330e24edafaacd0d2f012282526e096a90b33a

https://github.com/web-platform-tests/wpt/blob/master/fetch/compression-dictionary/dictionary-fetch-timing-001.tentative.https.html somehow covers this

fred-wang · 2026-06-09T11:25:52Z

+  data-x="create link options from element">create link options</span> from <var>el</var> and
+  to <span>load a compression dictionary</span> given the result and <var>el</var>.</p>
+
+  <p>The <span>process a link header</span> step for this type of linked resource given a <span


Note that this is also used by https://html.spec.whatwg.org/#process-link-headers

(I guess the use case is even less important, but technically we should have WPT test for that too)

Sorry, I was talking about Early hints here:

https://html.spec.whatwg.org/#process-early-hint-headers

Tentative test for this: web-platform-tests/wpt#61119

This is currently only implemented in Firefox (as I mentioned this use case is probably not super important...)

…header and <link> element. This is currently not specified but there some discussions happening at whatwg/html#11620 and this is important for performance reasons. Bug: 522338661, 40255884 Change-Id: Id1494aa3693b24afaf75dae4e0f5ef5909fce9e1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7922747 Commit-Queue: Frédéric Wang Nélar <fwang@igalia.com> Reviewed-by: Patrick Meenan <pmeenan@chromium.org> Reviewed-by: Kent Tamura <tkent@chromium.org> Cr-Commit-Position: refs/heads/main@{#1655866}

…> element and DOM operations. This is currently not specified but there some discussions happening at whatwg/html#11620 crossorigin mutation will be handled in a follow-up CL. Bug: 522338661, 40255884 Change-Id: I6e473e56b7b2b79d3a037001644ac89b598cd4ae Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/8029960 Reviewed-by: Patrick Meenan <pmeenan@chromium.org> Reviewed-by: Kent Tamura <tkent@chromium.org> Commit-Queue: Frédéric Wang Nélar <fwang@igalia.com> Cr-Commit-Position: refs/heads/main@{#1656392}

…nk rel=compression-dictionary> This is currently not specified but is proposed at whatwg/html#11620 Bug: 522338661, 40255884 Change-Id: I9df45092e344588d4dc06cea0fc2fd4daf84caec Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/8036725 Reviewed-by: Patrick Meenan <pmeenan@chromium.org> Commit-Queue: Frédéric Wang Nélar <fwang@igalia.com> Cr-Commit-Position: refs/heads/main@{#1660503}

fred-wang · 2026-07-13T12:27:11Z

+   <li><p>If <var>request</var> is null, then return.</p></li>
+
+   <li><p>Set <var>request</var>'s <span data-x="concept-request-destination">destination</span> to
+   "<code data-x="">compression-dictionary</code>".</p></li>


Added a test for it at https://chromium-review.googlesource.com/c/chromium/src/+/8086393 (also fixing Chromium's implementation)

fred-wang · 2026-07-13T13:40:54Z

+   <li><p>Let <var>request</var> be the result of <span data-x="create a link request">creating a
+   link request</span> given <var>options</var>.</p></li>
+
+   <li><p>If <var>request</var> is null, then return.</p></li>


Covered by https://chromium-review.googlesource.com/c/chromium/src/+/8084469

…or load/error events on a <link rel=compression-dictionary>, a=testonly Automatic update from web-platform-tests [compression-dictionary] Add WPT tests for load/error events on a <link rel=compression-dictionary> This is currently not specified but is proposed at whatwg/html#11620 Bug: 522338661, 40255884 Change-Id: I9df45092e344588d4dc06cea0fc2fd4daf84caec Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/8036725 Reviewed-by: Patrick Meenan <pmeenan@chromium.org> Commit-Queue: Frédéric Wang Nélar <fwang@igalia.com> Cr-Commit-Position: refs/heads/main@{#1660503} -- wpt-commits: 98fb56764b469c8b4bfa8dcd176e0da2df1ac283 wpt-pr: 61218

https://html.spec.whatwg.org/#body-ok whatwg/html#11620

Spec PR: whatwg/html#11620 This is currently only implemented in Firefox but not covered by any test: https://searchfox.org/firefox-main/rev/5e465cbe324a291bb69aa85c5c4231e052cabe9a/netwerk/protocol/http/EarlyHintsService.cpp#106

…load/error event nor any fetch request. "create a link request" for an invalid URL returns null per https://html.spec.whatwg.org/#create-a-link-request so "load a compression dictionary" should return early per whatwg/html#11620 Bug: 522338661, 40255884 Change-Id: Id2f37d8c578a585200b88574ef1262048b98ded3 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/8084469 Reviewed-by: Patrick Meenan <pmeenan@chromium.org> Commit-Queue: Frédéric Wang Nélar <fwang@igalia.com> Cr-Commit-Position: refs/heads/main@{#1663433}

Per whatwg/html#11620, if crossorigin is "No Cors" we should default to Anonymous. Currently, Chromium departs from the spec and always forces request's mode to "cors" and request's credentials to "omit". This CL aligns Chromium's behavior on the spec PR under a runtime flag and adds corresponding WPT test. Bug: 522338661, 40255884 Change-Id: I30835aebc9df79b59e74747b0729efbc6df69457 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/8098207 Reviewed-by: Patrick Meenan <pmeenan@chromium.org> Commit-Queue: Frédéric Wang Nélar <fwang@igalia.com> Cr-Commit-Position: refs/heads/main@{#1663435}

…load/error event nor any fetch request. "create a link request" for an invalid URL returns null per https://html.spec.whatwg.org/#create-a-link-request so "load a compression dictionary" should return early per whatwg/html#11620 Bug: 522338661, 40255884 Change-Id: Id2f37d8c578a585200b88574ef1262048b98ded3 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/8084469 Reviewed-by: Patrick Meenan <pmeenan@chromium.org> Commit-Queue: Frédéric Wang Nélar <fwang@igalia.com> Cr-Commit-Position: refs/heads/main@{#1663433}

Per whatwg/html#11620, if crossorigin is "No Cors" we should default to Anonymous. Currently, Chromium departs from the spec and always forces request's mode to "cors" and request's credentials to "omit". This CL aligns Chromium's behavior on the spec PR under a runtime flag and adds corresponding WPT test. Bug: 522338661, 40255884 Change-Id: I30835aebc9df79b59e74747b0729efbc6df69457 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/8098207 Reviewed-by: Patrick Meenan <pmeenan@chromium.org> Commit-Queue: Frédéric Wang Nélar <fwang@igalia.com> Cr-Commit-Position: refs/heads/main@{#1663435}

…load/error event nor any fetch request. "create a link request" for an invalid URL returns null per https://html.spec.whatwg.org/#create-a-link-request so "load a compression dictionary" should return early per whatwg/html#11620 Bug: 522338661, 40255884 Change-Id: Id2f37d8c578a585200b88574ef1262048b98ded3 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/8084469 Reviewed-by: Patrick Meenan <pmeenan@chromium.org> Commit-Queue: Frédéric Wang Nélar <fwang@igalia.com> Cr-Commit-Position: refs/heads/main@{#1663433}

Per whatwg/html#11620, if crossorigin is "No Cors" we should default to Anonymous. Currently, Chromium departs from the spec and always forces request's mode to "cors" and request's credentials to "omit". This CL aligns Chromium's behavior on the spec PR under a runtime flag and adds corresponding WPT test. Bug: 522338661, 40255884 Change-Id: I30835aebc9df79b59e74747b0729efbc6df69457 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/8098207 Reviewed-by: Patrick Meenan <pmeenan@chromium.org> Commit-Queue: Frédéric Wang Nélar <fwang@igalia.com> Cr-Commit-Position: refs/heads/main@{#1663435}

…hanges to crossorigin attribute This is currently not specified but is proposed at whatwg/html#11620 Bug: 522338661, 40255884 Change-Id: Ia6f60eee7f0e5a3af9fb4bda9b0d0a483a3e5950 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/8027613 Commit-Queue: Frédéric Wang Nélar <fwang@igalia.com> Reviewed-by: Patrick Meenan <pmeenan@chromium.org> Cr-Commit-Position: refs/heads/main@{#1663692}

…onary>" is body-ok, a=testonly Automatic update from web-platform-tests Verify that <link rel="compression-dictionary>" is body-ok https://html.spec.whatwg.org/#body-ok whatwg/html#11620 -- wpt-commits: 9bc8141e0406b3018ee91490fa23be224f1ecab0 wpt-pr: 61193

…der as early hints, a=testonly Automatic update from web-platform-tests Test link rel=compression-dictionary header as early hints Spec PR: whatwg/html#11620 This is currently only implemented in Firefox but not covered by any test: https://searchfox.org/firefox-main/rev/5e465cbe324a291bb69aa85c5c4231e052cabe9a/netwerk/protocol/http/EarlyHintsService.cpp#106 -- wpt-commits: 27d2ee72d025342dd435074bc5f9b454d9d7191b wpt-pr: 61119

…lid URLs neither trigger any load/error event nor any fetch request., a=testonly Automatic update from web-platform-tests [compression-dictionary] Check that invalid URLs neither trigger any load/error event nor any fetch request. "create a link request" for an invalid URL returns null per https://html.spec.whatwg.org/#create-a-link-request so "load a compression dictionary" should return early per whatwg/html#11620 Bug: 522338661, 40255884 Change-Id: Id2f37d8c578a585200b88574ef1262048b98ded3 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/8084469 Reviewed-by: Patrick Meenan <pmeenan@chromium.org> Commit-Queue: Frédéric Wang Nélar <fwang@igalia.com> Cr-Commit-Position: refs/heads/main@{#1663433} -- wpt-commits: fe2e38df0b44dee73701b8fa7b4e3b56ccd8dced wpt-pr: 61348

…in handling with the spec PR., a=testonly Automatic update from web-platform-tests [compression-dictionary] Align crossorigin handling with the spec PR. Per whatwg/html#11620, if crossorigin is "No Cors" we should default to Anonymous. Currently, Chromium departs from the spec and always forces request's mode to "cors" and request's credentials to "omit". This CL aligns Chromium's behavior on the spec PR under a runtime flag and adds corresponding WPT test. Bug: 522338661, 40255884 Change-Id: I30835aebc9df79b59e74747b0729efbc6df69457 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/8098207 Reviewed-by: Patrick Meenan <pmeenan@chromium.org> Commit-Queue: Frédéric Wang Nélar <fwang@igalia.com> Cr-Commit-Position: refs/heads/main@{#1663435} -- wpt-commits: babeec89975126bd1a6d29b75f6285dc23ae64fd wpt-pr: 61352

…element are processed after changes to crossorigin attribute, a=testonly Automatic update from web-platform-tests [compression-dictionary] Make sure link element are processed after changes to crossorigin attribute This is currently not specified but is proposed at whatwg/html#11620 Bug: 522338661, 40255884 Change-Id: Ia6f60eee7f0e5a3af9fb4bda9b0d0a483a3e5950 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/8027613 Commit-Queue: Frédéric Wang Nélar <fwang@igalia.com> Reviewed-by: Patrick Meenan <pmeenan@chromium.org> Cr-Commit-Position: refs/heads/main@{#1663692} -- wpt-commits: 9fb9c273ff8ed6dda31c3326cc87d0624404ee3a wpt-pr: 61350

domenic reviewed Sep 4, 2025

View reviewed changes

domenic mentioned this pull request Sep 4, 2025

Add support for <link rel=compression-dictionary ...> #11619

Open

pmeenan force-pushed the dict branch from 7e2c161 to dac8718 Compare November 11, 2025 15:25

pmeenan requested a review from annevk November 11, 2025 16:49

domfarolino reviewed Nov 18, 2025

View reviewed changes

pmeenan force-pushed the dict branch 2 times, most recently from 3d454f8 to 6b1b201 Compare December 16, 2025 17:43

pmeenan added 6 commits February 11, 2026 10:53

Added support for link rel=compression-dictionary

05bf299

Fixed CORS mode processing and http link processing

868e03c

Fixed No CORS

25c321f

Fixed link header processing

763cdd8

Fixed algorithm scoping

c5ca086

Cleanup unnecessary language

c9b3eed

pmeenan force-pushed the dict branch from ac67d32 to c9b3eed Compare February 11, 2026 15:54

Set the destination instead of initiator

64d7121

fred-wang mentioned this pull request Jun 5, 2026

Removed tentative from compression dictionary tests web-platform-tests/wpt#54532

Open

fred-wang reviewed Jun 9, 2026

View reviewed changes

chromium-wpt-export-bot mentioned this pull request Jul 1, 2026

[compression dictionary] Add WPT test to check fetch timing for Link header and <link> element. web-platform-tests/wpt#61030

Merged

chromium-wpt-export-bot mentioned this pull request Jul 2, 2026

[compression dictionary] Add WPT test to check fetch timing for <link> element and DOM operations. web-platform-tests/wpt#61054

Merged

fred-wang reviewed Jul 13, 2026

View reviewed changes

fred-wang added a commit to web-platform-tests/wpt that referenced this pull request Jul 16, 2026

Verify that <link rel="compression-dictionary>" is body-ok

83aa00b

https://html.spec.whatwg.org/#body-ok whatwg/html#11620

fred-wang added a commit to web-platform-tests/wpt that referenced this pull request Jul 16, 2026

Verify that <link rel="compression-dictionary>" is body-ok

9bc8141

https://html.spec.whatwg.org/#body-ok whatwg/html#11620

fred-wang mentioned this pull request Jul 17, 2026

Add test to verify that link rel=compression-dictionary fetches can be blocked via connect-src web-platform-tests/wpt#61309

Merged

chromium-wpt-export-bot mentioned this pull request Jul 20, 2026

[compression-dictionary] Align handling of referrer and referrerpolicy with the spec PR. web-platform-tests/wpt#61416

Merged

Uh oh!

Conversation

pmeenan commented Sep 3, 2025 • edited by pr-preview Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pmeenan commented Sep 3, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

domenic commented Sep 4, 2025

Uh oh!

pmeenan commented Sep 4, 2025

Uh oh!

domenic commented Sep 8, 2025

Uh oh!

pmeenan commented Nov 11, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fred-wang Jul 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fred-wang Jul 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fred-wang Jul 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pmeenan commented Sep 3, 2025 •

edited by pr-preview Bot

Loading

fred-wang Jul 6, 2026 •

edited

Loading

fred-wang Jul 6, 2026 •

edited

Loading

fred-wang Jul 6, 2026 •

edited

Loading