Delta encoding in HTTP
Extracted elements (28)
A new 226 status code is introduced (rather than using Expires/Cache-Control hacks) because existing HTTP/1.0 caches forward unknown 2xx responses without caching them, preventing delta-encoded bodies from being stored and later served verbatim to non-delta-capable clients.
The HTTP message-generation sequence is formalized as: resource → variant → instance (with entity tag assigned) → entity-body (after instance-manipulation) → message-body (after transfer-coding). Delta encoding is explicitly an instance-manipulation applied after the entity tag is assigned.
The "range" token is registered as an instance-manipulation so that clients can specify via A-IM ordering whether range selection occurs before or after delta encoding, resolving the ambiguity between resuming a partial delta transfer and selecting a subrange of the original instance.
If the server does not implement the A-IM header or does not support any of the listed instance-manipulations, it silently generates a normal 200 (OK) response with a full copy of the instance, preserving backward compatibility with unmodified HTTP/1.1 behavior.
Sending "Vary: If-None-Match, A-IM" in 226 responses is insufficient to prevent non-IM-aware proxy caches from incorrectly "validating" a cached 226 response; the im cache-directive combined with no-store is the correct mechanism for safety.
A 226 (IM Used) response MUST include an ETag header field giving the entity tag of the current instance; it is not meaningful to associate an entity tag with the delta value itself.
A Delta-Base header MUST be included in a response whose IM header includes a delta-coding, if the request included more than one entity tag in its If-None-Match header field.
A delta-encoded response MUST carry a status code of 226 (IM Used) and MUST include an IM header field listing at least the delta-coding employed.
A server MUST NOT use a non-identity instance-manipulation for a response unless that instance-manipulation is listed in an A-IM header in the request.
A status-226 cache entry MUST NOT be used in response to a subsequent request if any IM header values from the cached response do not appear in the subsequent request's A-IM header, or if their order differs, or if the Delta-Base entity tag is not in the subsequent If-None-Match.
If a response uses more than one instance-manipulation, the instance-manipulations MUST be applied in the order in which they appear in the A-IM request-header field.
If an A-IM field is present and the server cannot send an acceptable response according to that field, the server SHOULD send a 406 (Not Acceptable) error response.
The imparam-name in an instance-manipulation parameter MUST NOT be "q", to avoid ambiguity with qvalue quality parameters defined in HTTP/1.1.
When a proxy or cache forwards the result of applying a delta response to a cached base instance, the forwarded response MUST carry the same Content-Encoding header field as the new (delta) response.
When a server generates a delta-encoded response, the list of content-codings used SHOULD be a prefix of the list it would have used without delta encoding, enabling the client to apply the delta without additional content-coding operations.
When an A-IM request header includes one or more delta-coding values, the request MUST contain an If-None-Match header field listing one or more entity tags from prior responses for the request-URI.
When the IM header includes both range selection and at least one other non-identity instance-manipulation, the IM header MUST indicate the order in which all instance-manipulations (including range selection) were applied.
The 226 (IM Used) status code signals that the server fulfilled a GET by returning a representation produced by one or more instance-manipulations on the current instance, rather than the full instance itself.
The A-IM request-header field lists the instance-manipulations (e.g., vcdiff, diffe, gzip, range) acceptable to the client, with optional qvalue preferences, analogous to Accept-Encoding.
The Cache-Control "im" directive allows a cache that understands A-IM/IM to ignore an accompanying "no-store" directive, so that 226 responses with max-age can be stored by delta-aware caches while remaining uncached by legacy caches.
The Cache-Control "retain" directive is a server hint suggesting that a delta-capable client should retain the associated cached instance as a potential base for future delta requests; an optional timeout parameter indicates how long the server plans to keep the base.
The Delta-Base entity-header field identifies the entity tag of the base instance used to compute a delta-encoded response, allowing the client to select the correct cached instance for reconstruction.
The IM response-header field lists the instance-manipulations applied by the server, in application order; a response including IM must carry status 226.
A new IANA-administered name space for instance-manipulation values is created; initial registrations include vcdiff, diffe, gdiff, gzip, deflate, range, and identity. New values require documentation in an RFC or equivalent permanent reference; assignment is First Come, First Served.
The IANA HTTP Status Code Registry is updated with a new value: 226 IM Used, as specified in section 10.4.1 of this document.
Delta encoding introduces a risk of data corruption if a client's cache is corrupt or if a delta implementation has a bug; the existing HTTP Content-MD5 and Digest Authentication mechanisms do not cover reassembled multi-message data, so a separate integrity mechanism is needed for delta-assembled instances.
An instance-manipulation value is encoded as "token [imparams]", where imparams is a semicolon-delimited parameter whose name (imparam-name) must not be "q"; the A-IM header extends this with an optional ";q=qvalue" quality preference.
Delta-Base header syntax: "Delta-Base" ":" entity-tag — a single entity-tag value identifying the base instance, carried as an entity-header in the 226 response.