Caching and content identity

Immutable file versions and a fresh catalog serve different purposes.

Version URLs do not change content

A published version always refers to the same uploaded bytes. Updates receive a new URL. This makes references predictable and lets browsers reuse a previously downloaded version.

Cache policy

Versioned files are sent with Cache-Control: public, max-age=300, immutable. The five-minute freshness window limits how long a compliant cache may continue serving a withdrawn version without revalidation. It is not a deletion guarantee for copies outside the service.

The JSON manifest and HTML pages use no-cache, so a browser should revalidate before reuse. Private management responses use no-store.

Link to the new version

After publishing an update, copy its new direct URL. Existing documents that reference an older URL continue to request that older version while it remains published.

Delivery providers

An intermediary can have additional cache behavior. This service does not automatically purge third-party caches. Publishing or withdrawal should be verified on the actual delivery domain before sharing a link.

User publication and delivery budgets

New user publications use no-store and a delivery policy check. Private account responses also use no-store. The origin delivery budget reserves the full version size for each admitted GET, including a partial download; a disconnected transfer can consume that reservation. HEAD does not consume a body reservation. This is an origin budget, not a claim to measure every byte served by an external CDN cache.