How HTTP Works
2xx · Success
< HTTP/1.1 226 IM Used

226 IM Used: HTTP Delta Encoding

226 IM Used is the response to a delta-encoded request under RFC 3229. See the A-IM and IM headers, how it works, and why almost nothing implements it.

Reviewed 2 min readadvanced3 sourcesTry itMarkdown
Cacheable
Only with explicit freshness
Client action
Apply the delta to your cached copy
Usually sent by
Origin (delta encoding)
Spec
RFC 3229 §10.4.1
On this page

TL;DR: 226 IM Used is the success status for RFC 3229 delta encoding: the client says which cached version it holds, and the server replies with just the difference. It is registered with IANA but not implemented by browsers or mainstream servers, so you are unlikely to meet it.

How it works

The client sends the ETag of the version it already has in If-None-Match, and lists the delta formats it can apply in A-IM. If the server can produce a delta against that version, it replies 226 with IM naming the format used.

GET /feed.xml HTTP/1.1
Host: example.com
If-None-Match: "v41"
A-IM: vcdiff, gzip

HTTP/1.1 226 IM Used
ETag: "v42"
IM: vcdiff
Delta-Base: "v41"
Content-Length: 812
Cache-Control: no-cache

...vcdiff delta bytes...

The client applies the delta to its stored copy "v41" to reconstruct "v42". If the base is not available, the server can send the full response with 200 as usual.

The original use case was RSS and Atom polling, where each fetch re-downloaded a feed that had changed by a single item. Servers had to keep or compute deltas per base version, caches in the middle needed to understand Delta-Base, and clients needed patch code. Gzip and 304 Not Modified turned out to get most of the benefit.

Why it did not catch on

Three things worked against it. Delta generation needs the server to retain old versions or compute a diff per client base, which does not scale on a CDN where each edge node sees different clients. Intermediaries that do not know A-IM cannot cache the delta response safely, because the same URL and the same request headers (apart from If-None-Match) produce different bodies. And clients need a diff library for every format they advertise, plus a way to fall back when the base copy has been evicted. A plain 304 plus gzip wins on simplicity.

The IANA registry still lists 226 under RFC 3229, so tools such as status code enumerations and the Python http.HTTPStatus enum include it. That is the most likely place you will meet the name.

Practical notes

  • 226 is not in RFC 9110’s list of status codes that are cacheable by default, so send explicit freshness headers if you ever implement it.
  • Clients must not send A-IM to arbitrary servers expecting the feature to work. A normal server ignores it and returns 200, which is the safe fallback.
  • If you want incremental sync today, design it into the API (a since cursor, If-None-Match with 304, or a change stream), not into the protocol layer.

Try it with curl

226 IM Used comes from delta encoding (RFC 3229), which almost no server or CDN implements. If a server does, you ask for it with A-IM plus the ETag of the version you already hold, and the reply carries an IM header naming the delta format. curl does not apply deltas, it only shows the response.

curl -i -H 'If-None-Match: "v41"' -H 'A-IM: vcdiff, gzip' https://example.com/feed.xml

Frequently asked questions

What does 226 IM Used mean?

The server applied one or more instance manipulations, typically a delta, to the current representation and the response body contains the result. It is the success status for delta encoding as defined by RFC 3229.

Will I ever see 226 in production?

Almost certainly not. Delta encoding for HTTP was proposed in 2002 and never gained mainstream support in browsers, CDNs or servers. Seeing 226 usually means a custom or legacy feed server.

How is it different from a Range request with 206?

206 returns a contiguous byte slice of the current resource. 226 returns a computed difference between a version the client already has, identified by its ETag in If-None-Match, and the current one, which the client applies to its cached copy.

Should I implement delta encoding?

Probably not. Compression plus conditional requests (ETag, 304) covers most of the savings, and the deltas must be computed per client version. Applications that need incremental updates tend to expose them in the API instead, such as a changes feed.

Sources

  1. MDN Web Docs: 226 IM Useddeveloper.mozilla.org
  2. RFC 3229: Delta encoding in HTTPrfc-editor.org
  3. IANA HTTP Status Code Registryiana.org

Keep going

Browse /search