Frontend interview: How would you safely canary Compression Dictionary Transport?

Prompt and context

A documentation site generates similar HTML, CSS, and JavaScript on every release. The team wants later responses to reuse an earlier response as a Brotli or Zstandard dictionary to reduce repeated bytes, but browser support is not uniform and some responses contain private user data. Design a canary, cache, and security plan using Compression Dictionary Transport.

RFC 9842 defines a flow in which a response advertises a dictionary with Use-As-Dictionary, a client offers an available dictionary with Available-Dictionary, and both sides negotiate a dictionary content encoding. The specification requires HTTPS secure contexts; MDN currently labels the capability Limited availability, so it cannot be a mandatory path for every browser.

What the interviewer is testing

Can you explain dictionary registration, matching, hash negotiation, encoding choice, and ordinary-compression fallback?
Can you handle freshness, cache keys, release versions, CDNs, and consistency across nodes?
Can you recognize content-inference or compression side-channel risk from shared dictionaries?
Can you design progressive enhancement around browser capability, HTTPS, and response readability?
Can you prove byte savings without increasing errors or privacy exposure?

Questions to clarify first

Do target browsers, WebViews, proxies, and the CDN support the relevant dictionary encodings? Can the rollout be Chromium-only?
Which responses are public, same-origin, and repetitive, and which contain user, tenant, or authorization data?
Who creates, signs, expires, and rolls back dictionaries, and are release versions bound to resource hashes?
Are caches separated by language, tenant, authorization state, and content encoding?
Does the site already use Brotli, Zstandard, ETag, Early Hints, or service-worker caching?

30-second answer

"I would select public, same-origin, highly repetitive resources by browser capability and sensitivity. Over HTTPS, the server advertises a versioned dictionary with Use-As-Dictionary; after Available-Dictionary, it chooses dcb, dcz, or ordinary Brotli/gzip. Dictionary and content versions, hashes, and cache variants stay isolated, and sensitive responses do not share dictionaries. I would canary Chromium and a small resource set, measure bytes, decode errors, cache hits, and privacy alerts, and fall back to ordinary encoding whenever support or validation fails."

Step-by-step deep dive

Select the right resources. Start with static, public, same-origin, version-stable resources. Exclude personalized HTML, account data, cross-tenant responses, and secrets. Measure repetition and dictionary benefit before accepting the added complexity.

Build the negotiation flow. A response uses Use-As-Dictionary to declare a match, type, identifier, and freshness. A client with a match sends an Available-Dictionary hash and advertises dictionary encodings in Accept-Encoding. The server returns dcb or dcz only when both sides support it and the dictionary is fresh; otherwise it uses ordinary encoding.

http

HTTP/2 200
Content-Type: text/javascript
Cache-Control: public, max-age=3600
Use-As-Dictionary: match="/assets/*", id="docs-v42", type="dictionary"

HTTP/2 200
Content-Encoding: dcb
Vary: Accept-Encoding, Available-Dictionary

Fix the consistency boundary. Dictionary ID, resource version, and content hash belong in one release artifact. Every CDN node must obtain the same dictionary; half the nodes must not return an old dictionary while the rest use a new encoding. Vary and cache keys must cover request headers that change the representation, preventing a dictionary response from reaching an unsupported client.

Handle freshness and rollback. When a dictionary expires, is revoked, or no longer matches the content version, stop advertising it and fall back to ordinary compression. Keep old dictionaries for a controlled overlap window with a hard retirement time. Rollback should remove the advertisement, purge CDN variants, and restore Brotli/gzip; it should not depend on clients clearing caches.

Isolate privacy risk. Protect dictionary content like same-origin public resources. If an attacker controls part of the input and can observe compressed sizes, repeated substrings may reveal dictionary or response content. Keep secrets out of the same compression context as attacker-controlled text, and disable dictionary compression when needed. HTTPS protects transport but does not remove compression side channels.

Use progressive enhancement. Capability or negotiation failure continues with Brotli, gzip, or an uncompressed response. Start with a small static-resource and browser cohort. Compare Content-Encoding distribution, transferred bytes, TTFB, decode errors, cache hits, and fallback rate; withdraw the feature if gains are unstable.

Model answer

I would limit the first rollout to public, same-origin, versioned static resources with high repetition, excluding personalized HTML, tenant data, and secrets. Over HTTPS, the server advertises a dictionary with an ID, match scope, and expiry through Use-As-Dictionary. Only after the client sends Available-Dictionary and negotiates Accept-Encoding would the server return dcb or dcz; unsupported clients, stale dictionaries, and hash mismatches use ordinary Brotli/gzip.

The release artifact would include the dictionary, resource hashes, and CDN cache variants so every node is consistent. Vary isolates encoding and dictionary request headers. I would never place attacker-controlled input and secrets in the same compression context; HTTPS does not eliminate size-based side channels. The canary starts with Chromium and a small static set, measuring bytes saved, cache hits, decode errors, fallback, and privacy alerts. A rollback removes the dictionary advertisement and restores ordinary encoding.

Common mistakes

Symptom: Enable shared dictionaries for every response → Why it fails: Personalized or sensitive data enters an inferable compression context → Fix: Use public static resources only and ordinary compression for sensitive responses.
Symptom: Check only Accept-Encoding and ignore dictionary hash and freshness → Why it fails: The client may use the wrong dictionary or fail to decode → Fix: Bind ID, hash, version, and expiry.
Symptom: Cache only by URL at the CDN → Why it fails: A dictionary response may reach an unsupported client → Fix: Separate encoding, dictionary headers, and resource versions with Vary and cache keys.
Symptom: Treat HTTPS as the complete security guarantee → Why it fails: Compression side channels can still reveal repeated substrings → Fix: Isolate attacker-controlled input from secrets and disable dictionary compression when needed.

Follow-up questions and responses

What happens when a browser does not support it?

The server returns dcb or dcz only after successful dictionary negotiation. Other requests continue with Brotli, gzip, or no compression; monitor fallback and never require an upgrade to access the page.

How long should a dictionary live?

Set lifetime from release cadence, repetition benefit, and revocation speed, and encode the choice in release policy. Use a short overlap during static-version changes, then retire the old dictionary and purge CDN variants instead of keeping it indefinitely.

How do you test decoding and cache correctness?

Test supporting and non-supporting browsers, HTTP/1.1, HTTP/2, different CDN nodes, and cold and warm caches. Verify Vary, content hashes, decoded bytes, 304 responses, origin fetches, and ordinary-encoding fallback, not just compression ratio.

What signals make you disable it immediately?

Cross-user content mixing, dictionary hash mismatch, decode errors, cache poisoning, anomalous compressed sizes, or privacy-scan alerts should remove Use-As-Dictionary immediately. Restore ordinary encoding and preserve the incident metrics.

References

Compression Dictionary Transport (RFC 9842)
MDN Compression Dictionary Transport
Chrome for Developers: Improving Google Search with Compression Dictionaries
Chromium Compression Dictionary Transport documentation

Interview checklist

Start with public static-resource selection and negotiation headers. Then cover dictionary versions, cache keys, HTTPS, side channels, progressive enhancement, and rollback. Validate benefit with byte, cache, and error metrics.

One-sentence takeaway

Shared dictionaries reduce repeated bytes only when resource isolation, version hashes, browser fallback, and privacy guardrails are all in place.