226 - IM Used

What Does IM Used Mean?

A 226 status represents "Efficiency via Diffs." Instead of re-sending a 10MB file when only 1KB has changed, the server sends a 226 response containing only the delta (Instance Manipulation). The client must have a valid base version (tracked by ETags) and the correct algorithm (e.g., vcdiff) to reconstruct the final resource. If the client or any proxy in between doesn't support this specialized handshake, the operation fails or falls back to a standard 200 OK.

Common Causes

• -Specialized Data Sync: High-frequency data synchronization where only small increments of large datasets change.
• -Unsupported Delta Algorithm: The server sends a delta using an algorithm (like gdiff) that the client library cannot process.
• -Proxy Interference: Intermediate proxies or CDNs stripping the A-IM (Accept-Instance-Manipulation) header, forcing the server to return 200 OK instead of 226.
• -Cache Mismatch: The client's cached base version has an ETag that doesn't match the reference version used by the server to compute the delta.

How to Fix IM Used

1. 1Implement Fallback: If you receive 226 but can't process deltas, retry the request without the A-IM header to get the full resource (200 OK).
2. 2Sync ETags: Ensure your client correctly sends If-None-Match or If-Match so the server knows exactly which base version you have.
3. 3Proxy Configuration: If using Nginx or HAProxy, ensure it is configured to forward A-IM and IM headers without modification.
4. 4Clear Cache: If reconstructed data appears corrupted, wipe the local base version and perform a fresh "full" GET request.

Step-by-Step Diagnosis for IM Used

1. 1Confirm the presence of the IM (Instance Manipulation) header in the 226 response to identify the algorithm used.
2. 2Verify the A-IM header was sent in the request; without it, a server should never return 226.
3. 3Compare the reconstructed file size with the expected full resource size.
4. 4Check if the client library (e.g., Axios/Fetch) is throwing an "Unknown Status Code" error, as 226 is not in many default success lists.

curl -v -H "A-IM: vcdiff" -H 'If-None-Match: "v42"' \
     https://api.errorreference.com/v1/sync-data
# Expected 226:
# < HTTP/1.1 226 IM Used
# < IM: vcdiff
# < ETag: "v43"
# (Binary delta follows)

const fetchData = async (url, etag) => {
  const res = await fetch(url, { headers: { 'A-IM': 'vcdiff', 'If-None-Match': etag } });
  
  if (res.status === 226) {
    // Check if we have the tools to apply delta
    if (!canApplyDelta('vcdiff')) {
      return fetch(url); // Fallback to full 200 OK
    }
    // Apply delta logic...
  }
  return res.json();
};

How to Verify the Fix

• -Successfully reconstruct the full resource from the 226 delta and verify its hash against a standard 200 OK response.
• -Confirm that removing the A-IM header from the request causes the server to return 200 OK with the full body.
• -Ensure no intermediate proxy is caching the 226 delta as if it were a full 200 OK response.

How to Prevent Recurrence

• -Modern Alternatives: For new systems, prefer JSON Patch (RFC 6902) or GraphQL Subscriptions over 226 delta encoding, as they have better library support.
• -Header Transparency: Include A-IM and IM in your "Allowed Headers" list for all WAF and CDN configurations.
• -Documentation: Clearly mark endpoints that support 226, as most developers will mistake it for a server error if undocumented.
• -Pro-tip: 226 is extremely rare in 2026 because Brotli/Gzip and HTTP/2/3 header compression provide similar efficiency with much less architectural complexity.

Related Errors

Decision Support

Official References

• -MDN Web Docs: 226 IM Used
• -RFC 3229: Delta Encoding in HTTP
• -RFC 3229 Section 10.4.1 (Delta Encoding in HTTP)
• -HTTP Official Documentation