< HTTP/1.1 226 IM Used226 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.
- 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
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-IMto 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
sincecursor,If-None-Matchwith 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
Related
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
Related
206 Partial Content: Range Requests Explained
206 Partial Content returns only the byte range requested. See a curl transcript, Content-Range, If-Range, video seeking and resumable downloads.
HTTP 200 OK: What It Means and When to Use It
200 OK means the request succeeded and the response carries the result. What a 200 should contain, and when 201, 204 or 206 is the better answer for your API.
202 Accepted
The request was accepted for processing but not completed yet. Learn when to use 202 for asynchronous operations.
203 Non-Authoritative Information
203 means a proxy modified the origin response before passing it on. Learn when it is sent, how it differs from 200, caching rules and what clients should do.