IM Used
ActiveHTTP 226 IM Used indicates the server fulfilled a GET request and the response is the result of instance-manipulations applied to the current instance. Defined in RFC 3229 §10.4.1. The client applies the returned delta to its cached copy rather than treating it as a full replacement.
Description
The 226 IM Used status code means the server has successfully fulfilled a GET request for the resource, and the response body contains a representation of the result of one or more instance-manipulations applied to the current instance. Rather than sending the entire resource again, the server sends only the differences — a delta — that the client should apply to its previously cached copy.
The mechanism relies on two headers working in tandem. The client sends an A-IM (Accept-Instance-Manipulation) header declaring which delta encoding algorithms it supports — such as vcdiff, diffe, or the generic delta type. The server, if it can satisfy the request with one of those algorithms, responds with 226 and includes an IM header indicating which manipulation was actually applied. The client then patches its cached instance with the delta payload.
This approach was designed for bandwidth optimization on large resources that change incrementally — think RSS feeds with one new entry, documents with a few edited paragraphs, or database snapshots where only a handful of rows changed. Instead of retransmitting megabytes, the server sends kilobytes of diff. The savings compound on metered connections or high-frequency polling scenarios.
226 is distinct from 304 Not Modified. A 304 says 'nothing changed, use your cache as-is.' A 226 says 'things changed, here's a patch to bring your cache up to date.' The client MUST have a valid cached instance to apply the delta against — without one, the delta is useless.
In practice, 226 is extremely rare. Most systems opt for standard conditional GETs (returning 304 or a full 200), HTTP/2 server push, or application-level diffing. The complexity of implementing delta encoding at the HTTP layer — managing cached instances, negotiating IM types, handling failed patches — has kept adoption near zero outside of specialized systems.
Examples
GET /feeds/tech-news.xml HTTP/1.1
Host: feeds.example.com
If-None-Match: "v42-abc789"
A-IM: vcdiff, diffe
Accept: application/xmlHTTP/1.1 226 IM Used
Content-Type: application/xml
ETag: "v43-def012"
IM: vcdiff
Delta-Base: "v42-abc789"
Content-Length: 1847
[binary vcdiff delta payload]GET /api/database/snapshot HTTP/1.1
Host: data.example.com
If-None-Match: "snap-2024-01-14"
A-IM: vcdiff, delta
Accept: application/octet-streamHTTP/1.1 226 IM Used
Content-Type: application/octet-stream
ETag: "snap-2024-01-15"
IM: delta
Delta-Base: "snap-2024-01-14"
Content-Length: 4096
[delta payload representing changed rows]GET /docs/large-report.pdf HTTP/1.1
Host: docs.example.com
A-IM: vcdiff
Accept: application/pdf
--- Server responds with full 200 (no If-None-Match provided) ---
HTTP/1.1 200 OK
Content-Type: application/pdf
ETag: "report-v7"
Content-Length: 2458000Edge Cases
- •The client MUST have a previously cached instance matching the Delta-Base ETag — without it, the delta cannot be applied and the client must request the full resource.
- •If the delta application fails (corrupted payload, mismatched base), the client should discard the delta and issue a fresh unconditional GET to rebuild its cache.
- •The server is NOT obligated to honor A-IM — it may respond with a standard 200 and full body at any time, especially if the delta would be larger than the full resource.
- •Multiple instance-manipulations can be composed — the IM header may list multiple algorithms applied in sequence (e.g., 'IM: delta, gzip'), and the client must reverse them in order.
- •226 cannot be used with Range requests — delta encoding and byte-range serving are incompatible mechanisms addressing different optimization needs.
- •Intermediary caches (CDNs, proxies) that don't understand 226 may mishandle the response — they might cache the delta as if it were the full resource, corrupting downstream clients.
- •The Delta-Base header identifies which cached version the delta is computed against — if the client's cache doesn't match this ETag, the delta is unusable.
When You'll See This
- →RSS/Atom feed aggregator polling a feed with thousands of entries where only 2-3 new items appear per poll
- →Large document repository where clients sync multi-megabyte files that change paragraph-by-paragraph
- →Database replication over HTTP where only changed rows need to be transmitted
- →Firmware update servers sending binary diffs instead of full images to bandwidth-constrained IoT devices
- →Scientific dataset distribution where daily snapshots differ by fractions of a percent
- →Configuration management systems polling large config files that change one line at a time
Implementation References
| Language | Constant |
|---|---|
| Go | http.StatusIMUsed (since Go 1.7) |
| Rust | http::StatusCode::IM_USED |
| Python | http.HTTPStatus.IM_USED |
| Node.js | http.STATUS_CODES[226] |
| .NET | HttpStatusCode.IMUsed |
| Java | 226 (no built-in constant; use raw int) |
| PHP | Response::HTTP_IM_USED (Symfony) |
| Ruby | :im_used (Rack) |
History
Introduced in RFC 3229 'Delta Encoding in HTTP' (January 2002) by Jeffrey Mogul, Balachander Krishnamurthy, Fred Douglis, Anja Feldmann, Yaron Goland, Arthur van Hoff, and Daniel Hellerstein. The RFC addressed a real bandwidth problem: large resources that changed incrementally were being retransmitted in full on every request. The authors proposed a general framework where clients and servers negotiate delta algorithms via new headers (A-IM and IM), with 226 as the success signal. Despite elegant design, adoption never materialized at scale. HTTP/2's multiplexing, improved compression, and the shift toward smaller API payloads reduced the need. Most implementations that need diffing do it at the application layer (JSON Patch, operational transforms) rather than at the HTTP transport layer.
Related Status Codes
Related Headers
FAQ
What is the difference between 226 IM Used and 304 Not Modified?
304 Not Modified means the resource has NOT changed since the client's cached version — the client can use its cache as-is without any modification. 226 IM Used means the resource HAS changed, but instead of sending the full new version, the server sends a delta (difference) that the client applies to its cached copy to reconstruct the current version. Think of 304 as 'no update needed' and 226 as 'here's a patch to apply to your cache'. Both save bandwidth, but 226 handles the case where the resource actually changed.
Why is HTTP 226 so rarely used in practice?
Several factors killed adoption: (1) Implementation complexity — both client and server must support delta negotiation, cache management, and patch application. (2) HTTP/2 and HTTP/3 reduced the bandwidth problem through header compression, multiplexing, and server push. (3) Most APIs moved toward small JSON payloads where full retransmission is cheap. (4) Application-layer solutions (JSON Patch RFC 6902, operational transforms, CRDTs) handle diffing more naturally within domain logic. (5) CDNs and intermediary proxies often don't understand 226, creating caching hazards. The cost-benefit ratio rarely favors HTTP-layer delta encoding over simpler alternatives.
What does A-IM stand for and how does it work with the IM response header?
A-IM stands for Accept-Instance-Manipulation. It's a request header the client sends to declare which delta encoding algorithms it can process — for example, 'A-IM: vcdiff, diffe, delta'. The server picks one it can produce, computes the delta from the client's cached version (identified by If-None-Match ETag) to the current version, and responds with 226 plus an IM header naming the algorithm used (e.g., 'IM: vcdiff'). Common IM types defined in the RFC ecosystem: 'delta' (generic, RFC 3229), 'vcdiff' (RFC 3284, a binary diff format), and 'diffe' (entity-level diff). The client reverses the named manipulation to reconstruct the full current resource.