ErrorBase
Independent technical referenceOfficial site
  • Software and digital services
  • HTTP service

226

HTTP 226 IM Used status: delta instance manipulation applied

Verified with sources2 sourcesReviewed Oct 19, 2026
Technician coming? See the 2 steps they must show you

Risk level

Low

Usually safe to check without specialist tools.

Urgency

Medium

Quick answer

HTTP 226 (IM Used) is a 2xx success code showing the server fulfilled a GET request and returned the result of one or more instance manipulations, such as a delta against a cached base copy. Check the request A-IM and response IM, ETag, and Delta-Base headers before blaming the server.

Safety first

Stop and check this first

  • Never pass a raw 226 response body directly to an application parser without applying the instance-manipulations listed in the IM header and verifying the Delta-Base entity tag; doing so silently corrupts data.

Safe checks you can perform

  • Inspect the request A-IM header and the response IM header
  • Compare If-None-Match, Delta-Base, and the response ETag against the local base copy
  • Send a plain GET without A-IM and compare with the reconstructed instance

Leave these tasks to a qualified professional

  • Do not attempt this professional task: Update client HTTP logic to combine 226 deltas or omit A-IM
  • Do not attempt this professional task: Verify Delta-Base and ETag handling on origin servers and intermediate caches

What a technician must be able to justify

Technician visit

These are the steps they must carry out and show you. Tick them as they work: if steps are skipped, do not accept a part swap.

These are not instructions for opening or handling the equipment yourself. They are the checks that should support a technical conclusion.

  1. Update client HTTP logic to combine 226 deltas or omit A-IM

    What they doHave the application developer either implement the RFC 3229 instance-manipulation combiner for the formats advertised in A-IM (verifying Delta-Base and updating headers per Section 10.4.1) or stop sending A-IM on clients that cannot apply deltas.

    They must show youa test trace where either the reconstructed 226 output matches the 200 OK representation for the same ETag or the client request without A-IM receives 200 OK.

    In writingthe exact A-IM header policy or delta decoder version deployed in the client release.

  2. Verify Delta-Base and ETag handling on origin servers and intermediate caches

    What they doHave the API owner or CDN administrator verify that every 226 response includes the current ETag header, includes Delta-Base whenever If-None-Match lists multiple tags, and is combined only with the matching base cache entry.

    They must show youcaptured origin and cache response headers showing IM, ETag, and Delta-Base on a conditional GET exchange.

    In writingthe server or proxy configuration change and the verified header trace from production or staging.

Before accepting a part or repair

Nothing has been shown yet. Do not accept a part swap based on the code alone.

Follow these steps

Note: Follow the documented order. An error code identifies the affected system, but it does not prove by itself which part has failed.

  1. Inspect the request A-IM header and the response IM header

    No special tools

    Who:
    Your web developer or API engineer, using browser developer tools or a command-line HTTP client.
    How:
    Capture the raw GET request and 226 response headers and check whether the request includes A-IM and which instance-manipulations the response lists in IM (for example vcdiff, diffe, deflate, or range).
    Result that matters:
    Whether the 226 response was explicitly negotiated by the client and which transformation sequence the server applied.
    If the GET request lacks an A-IM header field, that confirms the server or intermediary violated RFC 3229 Section 10.4.1 by sending 226 uninvited.
    If A-IM is present in the request and IM is present in the response, that rules out an unsolicited status and isolates the issue to how the client decodes the listed manipulation.
    Evidence to keep:
    Save the complete request and response header block, including A-IM, IM, Content-Length, and status line, with authentication tokens redacted.

    Never disable TLS, authentication, or security headers to inspect HTTP 226 headers; redact session cookies and bearer tokens from saved traces.

    Evidence: IANA HTTP Status Code Registry · RFC 3229 - Delta encoding in HTTP

  2. Compare If-None-Match, Delta-Base, and the response ETag against the local base copy

    No special tools

    Who:
    Your developer or caching administrator.
    How:
    Read the entity tag sent by the client in If-None-Match, the base entity tag returned in Delta-Base (mandatory when If-None-Match lists multiple entity tags), and the current instance ETag in the 226 response.
    Result that matters:
    Whether the client or proxy is applying the delta against the exact base instance version used by the server.
    If the local cached entity tag does not match Delta-Base or the single If-None-Match tag, that points to a stale or mismatched base entry in the client or proxy cache.
    If the base entity tag matches and the response includes the new ETag header, that rules out a base-version mismatch and points to the delta decoding routine.
    Evidence to keep:
    Record the exact ETag, Delta-Base, and If-None-Match values along with the byte size of the local base copy.

    Evidence: RFC 3229 - Delta encoding in HTTP

  3. Send a plain GET without A-IM and compare with the reconstructed instance

    No special tools

    Who:
    Your developer, testing against the same endpoint.
    How:
    Issue a fresh GET request for the same URI without A-IM or If-None-Match so the origin server returns a normal 200 OK full representation, and compare its bytes and ETag with the instance reconstructed from the 226 delta.
    Result that matters:
    Whether the delta combiner produces the exact current representation served on a full transfer.
    If the reconstructed file differs from the 200 OK payload having the same ETag, that confirms a bug in delta generation or client-side delta application.
    If both payloads and entity tags match byte-for-byte, that confirms delta encoding is working properly and any alert comes from a monitoring tool misclassifying 226 as an error.
    Evidence to keep:
    Keep the cryptographic hash and byte length of both the 200 OK response body and the reconstructed 226 output.

    Evidence: IANA HTTP Status Code Registry · RFC 3229 - Delta encoding in HTTP

Still not solved

If the error persists, stop here. See what the technician must do and show you.

Where this code applies

A code is meaningful only inside the right product and version context.

Primary scope

System
Software and digital services
Brand
HTTP
Product type
HTTP service

Known code variants

  • 226 IM usado
  • 226 IM usato
  • 226 IM Used
  • 226 IM utilisé
  • 226 IM verwendet
  • HTTP 226
  • HTTP status 226

What it means

IANA registers 226 as IM Used under RFC 3229 (Delta encoding in HTTP). In Section 10.4.1, RFC 3229 specifies that the server fulfilled a GET request and the response payload represents one or more instance-manipulations (listed in the IM header, such as vcdiff or diffe) applied to the current instance. The request must have sent an A-IM header, and the response must carry an ETag header for the current instance (plus Delta-Base when required). Status 226 alone never proves a server fault: corruption appears when a client or proxy treats a delta body as a full representation or combines it with the wrong base entity tag.

Warnings and stop conditions

  • Lowsource verified

    Never pass a raw 226 response body directly to an application parser without applying the instance-manipulations listed in the IM header and verifying the Delta-Base entity tag; doing so silently corrupts data.

    Evidence: RFC 3229 - Delta encoding in HTTP

Symptoms and causes

Probable causes · in order

  • Expected delta or instance-manipulation response negotiated via A-IMConfirmed

    The client sent a GET request with an A-IM header advertising supported instance manipulations (such as vcdiff, diffe, or deflate) and the origin server returned the manipulated payload with status 226 and an IM header.

    Evidence: IANA HTTP Status Code Registry · RFC 3229 - Delta encoding in HTTP

  • Client parser treating a 226 delta payload as a complete resourceCommon

    According to RFC 3229 Section 10.4.1, the actual current instance might not be available except by combining the 226 response with previous or future responses; rendering the raw body directly produces truncated or unreadable data.

    Evidence: RFC 3229 - Delta encoding in HTTP

  • Mismatched base instance ETag in the client or intermediate HTTP cachePossible

    RFC 3229 permits a cache or client to combine a 226 response with a cached base entry, using Delta-Base or If-None-Match to identify the base entity tag; applying the delta to a different base revision corrupts the reconstructed output.

    Evidence: RFC 3229 - Delta encoding in HTTP

Virtual technician

Does 226 still appear after these checks?

Answer a few questions to narrow down the likely cause and the safest next action. Guidance only - it never replaces a professional.

Start diagnosis

Sources and technical references

  1. 1

    IANA HTTP Status Code Registry

    Internet Assigned Numbers Authority · 2025 · standard

  2. 2

    RFC 3229 - Delta encoding in HTTP

    IETF / RFC Editor · 2002 · standard

Sources: IANA HTTP Status Code Registry · RFC 3229 - Delta encoding in HTTPreviewed 2026-10-19 · verified

Was this entry useful?