Summary

  • RFC 3229 added delta encoding to conditional GET: a client names cached instances with If-None-Match, advertises transformations with A-IM, and can receive 226 plus an IM description instead of another complete copy.
  • Three identities govern reconstruction. Delta-Base names the old instance, the body carries transformation data, and the response ETag names the current reconstructed instance—not the delta bytes.
  • The new status code was a compatibility barrier. An intermediary that ignored unfamiliar headers might otherwise cache a difference and later serve it as the whole resource. Saving bytes required making semantic incompleteness visible.

Conditional retrieval still had an all-or-nothing bill

Caching solved one kind of repetition early in the Web. If a stored response remained current, a conditional request could receive 304 Not Modified and avoid another copy. If the resource had changed, however slightly, the normal answer was the complete new value.

That made coherence binary. The old instance was either reusable without change or useless for transfer. A single altered paragraph could make the server send every unchanged paragraph again.

RFC 3229, published in January 2002, asked whether the cache could become more than a yes-or-no witness. If the client already held a prior instance, the server might send a description of the changes. Applying that delta to the old base would recover the current instance.

The proposal was deliberately optional. It sought smaller mean responses without another network round trip, supported more than one delta format, and had to coexist with HTTP/1.0 and HTTP/1.1 implementations that knew nothing about it. It did not promise that every resource or every change would produce a useful delta.

A delta was not a compressed copy

The mechanism depended on a vocabulary precise enough to keep different transformations apart. RFC 3229 defined an “instance” as what a 200 GET would return for the selected variant after content coding but before instance manipulation and transfer coding.

A delta is computed between instances. It is not merely a smaller serialization of the current one. Compression can decode without an older copy; a delta generally needs the particular base from which its differences were calculated.

Nor is it a byte range. A range selects coordinates from one current instance. A delta describes how one instance differs from another. A six-byte instruction might reproduce changes scattered across a document; a six-byte range is simply six selected bytes.

The distinction also separates 226 from PATCH. The 226 body is a response to GET and tells the recipient how to recover current representation state. It is not a request to mutate the resource. RFC 3229 expressly limited its defined mechanism to responses to GET.

The client had to show its prior knowledge

Delta service begins with evidence at the client. If-None-Match lists one or more entity tags for prior instances the client possesses. A-IM lists instance manipulations the client can accept, such as a delta coding.

If the named instance is still current, nothing has changed and the established 304 path remains correct. If it has changed, a capable server may select an offered base and compute a compatible delta. If the server lacks the base, does not support the manipulation or judges the calculation unhelpful, ordinary 200 remains available.

The request is therefore an offer, not an instruction. The client controls which bases it can actually reconstruct from and which formats it can decode. The origin controls which historical instances it retains, whether it performs the work and whether sending the whole is cheaper.

This negotiation prevents an optimistic guess. A server cannot safely send “the difference” until both parties agree what the difference is from and how it will be applied.

One response carried three identities

The reconstruction chain has three separate entities. The base instance already resides in a cache. The response body carries the delta instructions. The result after applying those instructions is the current instance.

When several base ETags were offered, Delta-Base tells the client which one the server chose. The ETag on the 226 response names the current instance that reconstruction produces. RFC 3229 explicitly warns that it is not meaningful to associate that ETag with the delta value, because the delta is not itself an instance.

This is the heart of 226. The message body can be correct without being a usable representation on its own. Its meaning is a function of a specific base, a specific manipulation and an intended result identity.

Content-Length follows the message at hand: it measures the delta body, not the reconstructed current instance. Treating that length as the length of the current resource would make protocol efficiency look like truncation.

Transformation order became part of the evidence

RFC 3229 placed instance manipulation in a larger message-generation sequence. The origin selects a resource and variant, applies any content coding, assigns the instance ETag, applies instance manipulations such as delta or range, and only then applies transfer coding.

These layers are not interchangeable. If multiple instance manipulations occur, their order is the order advertised and reported through A-IM and IM. Delta then range is not necessarily the same as range then delta. Compression as a content coding changes the instance against which an ETag and delta are understood; compression as a later manipulation changes a different layer.

The protocol therefore made ordering observable. A cache cannot retain a set of manipulation names and silently reorder them during replay. The reconstruction recipe includes sequence, parameters and the base identity.

Efficiency often tempts implementers to think only about bytes saved. Here, the metadata that explains how the bytes become a representation is part of the representation’s lineage.

Why another 2xx code was necessary

The designers initially resisted adding a status code. The eventual reason for 226 was not decorative taxonomy but deployed cache behavior.

HTTP recipients are generally expected to ignore header fields they do not understand. A legacy intermediary could therefore ignore IM, store the delta body, and later send those bytes to an unaware client that believed it had received a complete representation. A compatible extension would have produced silent corruption precisely because older software behaved as designed.

RFC 3229 used a new, unfamiliar success code as a safety boundary. The authors observed that existing proxies appeared to forward unknown statuses without caching them. An unaware component could still carry the response, but it was less likely to relabel the delta as ordinary 200 content.

The specification even states that Vary: If-None-Match, A-IM alone was limited public evidence for at least one incorrect validation path. The semantic break had to be visible somewhere legacy logic would not casually erase it.

IM said what happened; 226 said not to assume a whole

A delta-encoded response must use 226 and include IM, naming at least the delta coding employed. The request must have offered acceptable instance manipulation through A-IM and supplied a base through If-None-Match.

The status says the GET was fulfilled and the body represents the result of one or more manipulations applied to the current instance. Depending on those manipulations, the current instance might only become available by combining this response with previous or future responses.

The code does not mean “delta” in isolation. The framework can describe more than one instance manipulation, including combinations with range selection. IM carries the ordered recipe; 226 marks the response as manipulated.

That division avoids overloading the reason phrase. “IM Used” is intentionally short. Software needs the structured fields, not an English sentence, to recover the result.

Cache safety became an explicit capability

An unaware cache should not store manipulated bytes as an ordinary representation. A delta-aware cache, however, can use them productively. RFC 3229 defined special rules rather than banning storage altogether.

A capable cache may decode all manipulations, recover the current instance and store it as a normal 200 response. It may decode everything except range selection and store a proper 206 response. Or it may retain the raw 226 entry under the dedicated constraints.

Raw reuse is strict. The next request must accept the stored manipulations, including their relevant order and parameters. The cache still needs expiration, validation, base and response identity rules. A stored delta is not a free-standing variant that can answer any future GET.

The im Cache-Control extension supported this capability boundary. A carefully marked response could include no-store for ordinary caches while allowing an implementation that understood the full IM contract to follow the accompanying cache instructions.

Retaining the past had a price

Delta encoding saves transfer only if someone retains a suitable past. A client with several old instances can list several ETags. An origin with matching history may choose the base that yields a useful delta and identify it with Delta-Base.

But cache space is finite, origin history is finite, and computing several candidate deltas costs CPU, memory and I/O. A server hint that an instance may be worth retaining is not a promise that the origin will preserve it forever.

The optimization therefore changes storage incentives. Clients may keep older instances that are no longer directly displayable because they could become useful reconstruction bases. Servers may preserve versions or precompute deltas only where future savings justify the cost.

This is why optionality is structural, not a sign of failure. The server must remain free to return 200 when the delta is larger, slower, unavailable or operationally unreasonable.

Current registries preserve the vocabulary

The IANA HTTP Status Code Registry still registers 226 IM Used to RFC 3229. The IANA HTTP Field Name Registry lists A-IM, Delta-Base and IM as permanent fields.

Registration does not establish deployment prevalence. It establishes that the protocol symbols retain defined meanings. A receiver that encounters them can find the contract; an implementer cannot safely repurpose them for an unrelated “incremental” format.

The historical lesson is therefore not that every modern transfer became a delta. It is that HTTP found a way to express one when both sides and the cache path could preserve enough state to make the expression trustworthy.

The copy arrived only after reconstruction

HTTP 226 moved the boundary between message and representation. The wire could carry something smaller than the current instance without claiming that the smaller thing was the instance.

That saving depended on a chain of attribution: the client proved which old instance it held; the server chose and named the base; IM specified the ordered transformation; the response ETag named the reconstructed current state; caches either understood the chain or refrained from treating the bytes as a whole.

A delta without this chain is not efficient truth. It is an ambiguous patch of bytes whose apparent smallness conceals the state it assumes.

The status code’s quiet achievement was to make that dependence impossible to ignore. The recipient did not receive the new copy. It received a trustworthy way to make the new copy from something it could prove it already had.