226 是什么
226 IM Used 是 RFC 3229（HTTP 增量编码）定义的响应码：服务器对 GET 应用了一组实例操作（instance manipulation），返回的不是完整表示，而是基于某个基版本的增量。生效前提是客户端在请求里用 A-IM 声明接受哪些实例操作，响应里用 IM 说明实际应用的操作、用 Delta-Base 指向基版本（RFC 3229 §10.4.1）。
基本信息
| 名称 | 226 IM Used |
|---|---|
| 类别 | 2xx |
| 规范 | RFC 3229 §10.4.1 |
| 请求前提 | A-IM 头声明可接受的实例操作 |
| 响应头 | IM、Delta-Base |
| 示例算法 | diffe（RFC 3229 给出的 delta 算法） |
典型使用场景
- 理解 HTTP 增量传输的设计意图（节省带宽）
- 阅读抓包遇到 226 时判断响应体不是完整文档
- 实现或调试支持 delta 的中间层
- 评估是否值得自建 delta 编码（多数场景 gzip 与 br 已足够）
- 缓存系统设计：理清增量对象与基版本的关联关系
- 离线分发场景：比较增量更新与整包下发的成本
请求与响应示意
请求与响应示意
GET /doc HTTP/1.1
A-IM: diffe # 客户端声明接受 diffe 增量
HTTP/1.1 226 IM Used
IM: diffe # 实际应用的实例操作
Delta-Base: "abc123" # 增量所基于的实体标签（ETag）
# 客户端必须先取到 Delta-Base 指向的版本再打补丁相关头部
| 头部 | 方向 | 作用 |
|---|---|---|
| A-IM | 请求 | 声明可接受的实例操作 |
| IM | 响应 | 说明实际应用的实例操作 |
| Delta-Base | 响应 | 增量所基于的实体标签 |
| ETag | 双向 | 版本标识，增量正确性的前提 |
Delta-Base 指向的基版本一旦不匹配，增量就无法应用；这也是该机制难以大规模落地的主因。
Content-Encoding 负责压缩，IM 与 delta 负责「相对旧版本的变化量」，两者概念不同，不能互相替代。
现实中几乎没有部署：它要求客户端长期持有精确的基版本，而缓存与 CDN 会打乱这一前提。
若客户端未声明 A-IM，服务器必须返回 200 的完整表示，不能擅自返回 226。
增量机制对版本管理要求很高：任何基版本丢失都会导致整包重传，收益并不稳定。