CDN Cache Rules for Versioned Model Downloads

Direct answer

Treat a CDN as a delivery path, not as the authority for model identity. Publish an immutable artifact revision and bind the client’s manifest to that revision, the expected format, length when verified, and a trusted digest when one exists. Configure cache policy so an immutable URL cannot silently start serving different bytes; use a new URL or revision when the artifact changes. Revalidation and cache expiry govern whether an intermediary may reuse a stored representation, while a digest or equivalent trusted verification establishes whether the bytes match the expected artifact. Neither a successful HTTPS response nor a cache hit proves that the model content is the intended release. The repository does not establish that Cove currently uses a CDN. Its E2B configuration points at a pinned model repository commit, while the E4B configuration is marked as placeholder metadata and uses a mutable branch reference. The downloader supports a configured mirror and Range requests, but the current fact card explicitly says the E2B digest is empty and must not be called verified. These details are useful examples of why URL identity, cache behavior, mirrors, and integrity must remain separate. This guide describes a design and validation method; it does not assert an existing Cove CDN deployment or public artifact distribution. HTTP caching has distinct rules for freshness, validation, and storage. A fresh response may be reused according to its directives. A stale response can require revalidation with the origin, and the origin’s response determines whether a stored representation remains valid. For versioned model artifacts, mutable “latest” paths create ambiguity because a client can receive different bytes at the same URL over time. An immutable path lets release metadata identify the intended content and makes rollback a pointer or manifest decision rather than an in-place overwrite. Cache invalidation may be eventually propagated or scoped by a provider; never rely on a purge as the only integrity control. Range requests add another consistency boundary. A CDN may serve a partial response from a cached object, revalidate it, or retrieve it from origin. The client must validate status and Content-Range against the requested offset and expected representation. If an object changes while a transfer is interrupted, a range response from a different revision must not be appended to old bytes. Where supported and appropriate, representation validators such as ETag can help detect changes, but an ETag is not necessarily a cryptographic digest or proof of publisher identity. A client should bind validators to an immutable artifact policy and still verify a trusted digest where the product claims one. Cache headers also interact with access control and revocation. A publicly cacheable model file can remain available in intermediary storage after an origin-side change; private or signed delivery needs a policy for token scope, expiration, URL logging, and cache key behavior. Do not embed long-lived secrets in a URL likely to appear in logs or referrers. Conversely, do not set private/no-store directives reflexively without understanding how the CDN and client handle resumable transfer and revalidation. The correct policy depends on whether the artifact is public, access-controlled, revocable, or tied to a license. Those product facts must be verified before writing delivery promises. Test the actual chain, not just the origin. Capture the requested URL revision, redirect chain, cache status where available, response status, Content-Length, Content-Range, validators, body digest, and final installed artifact identity. Repeat with a cold cache, warm cache, stale object requiring revalidation, interrupted range transfer, origin revision change, rollback, and a deliberately mismatched response fixture. Use controlled non-production objects for destructive cache operations. The client must reject mismatched bytes even when every HTTP hop succeeds. A CDN’s reported HIT/MISS state can explain a path, but cannot replace artifact verification. For incident response, retain the manifest revision and response metadata needed to identify the served representation without recording credentials or user task content. A rollback should select a previously known artifact identity, then let clients fetch and verify it; do not mutate an existing version URL and expect every intermediary to notice immediately. If a model must be revoked, define how clients stop using a local artifact and how cached copies are treated, without promising deletion from infrastructure you do not control. Cache behavior, artifact provenance, and app-level activation are three separate operational concerns. ### Procedure 1. Define immutable artifact identity. Create a new versioned URL for each changed byte sequence and publish a manifest that binds the revision, format, measured length, trusted digest if available, and license/source records. Do not present placeholder metadata as release evidence. 2. Specify cache directives by artifact policy. Decide whether the object is public or access-controlled, how long it may be fresh, when it must revalidate, and whether revocation is supported. Document CDN cache-key and signed-URL behavior for the actual provider. 3. Validate range and validator behavior end to end. Request full and partial objects through the CDN, interrupt and resume, and verify status, Content-Range, validators, body identity, and final digest. Reject any response that could mix revisions. 4. Exercise cold, warm, stale, rollback, and mismatch fixtures. Record both CDN observations and client acceptance outcomes. A cache HIT with the wrong digest must fail; a MISS with the correct pinned bytes may pass verification. 5. Define rollback and revocation separately. Roll back by selecting an immutable known-good revision. If revocation is required, document app activation behavior and the limits of intermediary copies; do not claim a purge removed every cached copy. ### Acceptance criteria - Changed model bytes always receive a new immutable identity; a stable URL never silently changes its representation. - Cache freshness and revalidation policy is documented for the actual access model and does not substitute for integrity verification. - Range resume cannot append bytes from a different representation, and the final artifact is checked against trusted metadata when available. - Rollback selects a known artifact revision and does not require overwriting the working model before candidate validation. ### Comparison | Mechanism | Useful role | Limitation | |---|---|---| | Immutable versioned URL | Identifies a release representation | Does not itself verify received bytes | | Cache revalidation or purge | Controls reuse and freshness at intermediaries | Does not prove artifact provenance or universal immediate eviction | | Trusted digest verification | Compares bytes with expected content | Requires a digest obtained through a trustworthy release channel | ### FAQ **Does HTTPS plus a CDN cache hit prove the model is authentic?** No. HTTPS protects a connection to an endpoint, and a cache hit describes reuse behavior. Neither establishes that the publisher intended those exact bytes; bind an immutable artifact identity to trusted release metadata and verify it. **Should model URLs always use no-cache?** Not necessarily. Cache directives depend on whether an artifact is immutable, public or access-controlled, and how revalidation and revocation should work. A versioned immutable object can often be cached safely, but the actual policy must be tested through the chosen CDN. **Can an ETag replace SHA-256?** Not as a universal claim. ETag semantics are validators for representation state and may be generated by an intermediary; they are not guaranteed to be a cryptographic digest or publisher signature. Use them only for the role documented by the origin and client policy. **What if a CDN serves old bytes after a release update?** Avoid mutating the old URL. Publish a new immutable revision and update the signed or otherwise trusted manifest. Keep the previous known-good revision available for rollback while clients verify the new candidate.

A cache serves a model after its origin metadata changes

A team moves a large model artifact behind a CDN to reduce repeated origin transfers. A user interrupts a download and resumes later; meanwhile a release process updates metadata. The team needs to prevent a cached range from one revision being combined with bytes from another.

Decision

Use immutable versioned artifact identities, explicit cache revalidation rules, and client-side representation checks. Keep cache freshness separate from cryptographic verification and app activation.

Expected outcome

The client either verifies the exact pinned bytes or rejects the response and preserves the previously working artifact; a cache HIT alone never becomes a trust decision.

Evidence to collect

The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:

• Versioned URL
• Manifest digest
• Cache and revalidation test

A completed byte stream is not enough. Final placement, integrity, runtime load, and recovery must also pass.

Implementation workflow

1. Bind each byte sequence to a new identity. Use a versioned or content-addressed path that changes whenever the artifact bytes change. The release manifest should record source revision, format, measured size where known, and a trusted digest if one is available; unresolved placeholders must remain visibly unverified.
2. Choose freshness and revalidation deliberately. For the actual public or access-controlled delivery model, document freshness lifetime, revalidation behavior, cache-key inputs, signed URL expiry, and revocation expectations. Confirm the CDN honors those directives instead of assuming an origin header alone controls every intermediary.
3. Validate ranged responses through the cache. Test full and partial requests through the deployed path. Check status, Content-Range, validators, final revision, and body bytes before opening an append stream. If the representation differs from the saved partial file, reject or restart rather than joining them.
4. Separate cache observations from trust checks. Record HIT or MISS metadata only as operational context. Verify the final bytes against a trusted digest when available and preserve the distinction between transport success, integrity result, runtime load, and user-visible readiness.
5. Exercise rollback and stale-cache cases. Test a cold cache, warm cache, stale object, interrupted range, new release, rollback, and mismatched body. Keep a known-good immutable artifact available until the candidate verifies and loads; document the limits of cache purge and revocation.

Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.

Acceptance criteria

• A changed artifact always has a changed immutable URL or identity.
• Cache policy is defined for the real access model and cannot stand in for digest or provenance validation.
• Interrupted downloads reject range data that does not match the stored artifact identity.
• Rollback selects a known-good immutable candidate without overwriting the current working artifact first.

Decision table

Failure patterns to prevent

• Mutable latest URLs
• Trusting CDN status as integrity proof

Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.

Minimum reproducibility record

Release checklist

• ☐ The primary query is answered without an unsupported number.
• ☐ Every artifact and runtime is pinned.
• ☐ The representative task and failure policy are explicit.
• ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
• ☐ User-content and network boundaries are documented.
• ☐ Result wording applies only to the recorded configuration.
• ☐ The page links to raw method or evidence when results are added.

Sources and related evidence

• IETF HTTP Caching (RFC 9111)
• IETF HTTP Semantics (RFC 9110)
• Android app integrity and secure distribution overview

Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.

Frequently asked questions