v156 · request destination · CORS · referrer

Link request semantics

Add a <link rel="compression-dictionary"> with a chosen crossorigin and referrerpolicy, and read back the request the browser actually sent from a server echo. Chrome 156 sets Sec-Fetch-Dest: compression-dictionary and honours those attributes; older Chrome does not.

To see the Chrome 156 behaviour

Relaunch Chrome or Chrome Canary in a secure context with:

No chrome://flags single toggle covers the new alignment; these are Blink runtime features.

Declare a dictionary link, inspect the request

Choose attributes, then add the link. The page inserts a real <link rel="compression-dictionary"> pointing at the echo route and reports the headers the server received.
Request headers the server observed
headervalue the server sawChrome 156 expectation
Sec-Fetch-Dest—compression-dictionary
Sec-Fetch-Mode—cors / no-cors per crossorigin
Sec-Fetch-Site—same-origin
Referer—per referrerpolicy
Accept-Encoding—includes dcb, dcz

How the echo works

Because a request's destination cannot be read from JavaScript, the demo reads it where it is visible — on the server, as the Sec-Fetch-Dest header. The page inserts a <link rel="compression-dictionary" href=".../dict-echo/reflect?token=…">; the echo route records the request headers under that token; the page then fetches .../dict-echo/events?token=… to display them. If the echo route is not yet wired into the server, the panel says so plainly rather than inventing a result.

const link = document.createElement("link");
link.rel = "compression-dictionary";
link.href = "../dict-echo/reflect?token=" + token;
link.crossOrigin = "anonymous";        // Chrome 156 applies this to the fetch
link.referrerPolicy = "no-referrer";   // …and this
document.head.append(link);
// The browser fetches it with destination "compression-dictionary".

see also