Publish changes under a new URL
01A versioned resource keeps its old URL stable; a changed resource receives a new URL and updated references.
A newly updated page points to v2. A client following that new reference obtains v2 separately; a cached v1 does not turn into v2.
Source for this drawing: RFC 8246 · Read RFC section 1 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
- Representation
- The response content and metadata for a resource.
- Versioned URL
- An address that distinguishes one published resource version.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
A new version has a new address.
- Ordinary freshness permits cache reuse for a time; it does not promise that the origin has not changed the resource meanwhile.
- With versioned URLs, a publisher puts changed content at a new address and updates references. This pattern can support long freshness lifetimes.
- The immutable response directive communicates that the origin will not update this representation during its freshness lifetime. It does not mean that a website can never change.
The version labels v1/v2 and CSS bodies here are illustrative, not a required URL naming or content-hash scheme. Immutability is a server promise, not a content-integrity check. Existing references and cached responses do not magically switch to a new URL.
Read the RFC section ↗