Give changing files new names

A durable URL—one whose path means “latest” forever—must be purged every deploy. A fingerprinted URL names a particular generation and never needs that treatment. That is both the performance argument and the operational one.

1. Classify Keep index pages and explicit public extras stable. Everything else is a fingerprint candidate; state/version.txt is generated outside the visitor tree.
2. Rename Transparent mode adds an eight-character content hash and the UTC deployment date.
3. Rewrite References in HTML and CSS follow the assets to their new names.
4. Queue Stable paths join any unfinished and dropped durable paths in one queue, compacted deterministically to Front Door’s 100-path maximum.

The name carries content and age

The pattern is {basename}-{8 hex SHA-1}-{UTC YYYYMMDD}{ext}. The hash comes from the exact file bytes. The date is the deployment's UTC calendar date, not the file timestamp or commit author's clock.

Identical bytes deployed on a later day still receive a new object, making age visible to the future storage lifecycle job. The classifier accepts hashes from eight through forty characters so older full-SHA-1 objects continue taking the long-cache path without reclassification.

Two publishing modes

Mode	Who it is for	Behavior
Transparent	Plain HTML/CSS/JS sites	The library fingerprints eligible files and rewrites references automatically.
Passthrough	Static-site generators and bundlers	The library keeps emitted names, then classifies them: a hashed-looking filename gets long cache; everything else is stable and purgeable.

One detail surprises authors: only index pages are stable by default. Another HTML file such as about.html is fingerprinted unless it appears in extra_unhashed_paths. If visitors need a durable /about.html, opting it in is easy—but it should be an intentional promise, because that path joins every future purge.

A small, deterministic purge queue

Before public files change, deploy unions any unfinished queue with current durable paths and paths for dropped unhashed blobs. It verifies one state/to-purge-YYYYMMDD.txt, preserving the original unfinished date, before those dropped origin blobs are removed. Queue bodies contain only FQDN-relative contentPaths such as / and /docs/*.

Front Door accepts at most 100 paths. The queue first replaces the deepest, smallest overlapping directory groups with /dir/*, retaining /dir/ when its index cache key is separate. Only a set that still cannot fit falls back to /*. It never sends 100 and defers the remainder: exact entries and covering wildcards represent the whole set in one request. Fingerprinting keeps ordinary assets out of that finite operation.

Old fingerprints are intentionally long-lived. Deploy does not prune them from origin, purge them from Front Door, or include them in the public verification sweep. A changed asset gets a new URL; old objects remain available until the separate, still-planned storage lifecycle job eventually evaluates them.

Next: how browsers and the edge treat each class, how dropped durable paths are removed safely, or return to all posts.