HTTP 226 IM Used: instance manipulation

Cos'e HTTP 226 IM Used

Il codice HTTP 226 IM Used e definito dalla RFC 3229 e indica che il server ha applicato una o più instance manipulations alla risorsa richiesta, restituendo non l'intera entita ma una sua versione manipolata, tipicamente un delta rispetto a una versione già in possesso del client.

Cos'e l'instance manipulation

L'idea e ridurre il volume dei trasferimenti HTTP applicando trasformazioni note ad entrambe le parti. Esempi:

• Delta encoding: il server invia solo le differenze rispetto a una versione precedente.
• Range delta: combinazione di range request e delta per file di grandi dimensioni.
• VCDIFF: algoritmo di diff binario standardizzato (RFC 3284) usato come instance manipulation.

Header A-IM e IM

Il client dichiara le manipolazioni accettate con A-IM:

GET /resource HTTP/1.1
A-IM: vcdiff, gzip
If-None-Match: "v1-etag"

Il server risponde con IM per indicare quali manipolazioni ha effettivamente applicato:

HTTP/1.1 226 IM Used
IM: vcdiff
ETag: "v2-etag"
Delta-Base: "v1-etag"
Content-Type: application/vcdiff

Vantaggi

L'instance manipulation puo ridurre la banda di un'ordine di grandezza per risorse molto grandi che cambiano poco tra versioni: configurazioni applicative, feed RSS, dataset scientifici, bollettini meteo. Una pagina HTML da 200KB che modifica solo 1KB viaggia con un delta di pochi byte.

Differenza con la compressione

La compressione (gzip, brotli) riduce la singola risposta indipendentemente dalle precedenti. L'instance manipulation invece sfrutta la memoria condivisa client-server: il client deve avere già in cache la versione base referenziata da Delta-Base. E quindi una forma di cache delta-aware.

Adozione nella pratica

Nonostante l'efficienza teorica, il 226 ha avuto un'adozione molto limitata. Le ragioni:

• Complessita: implementare e mantenere generatori di delta server-side ha costi alti.
• Compressione "good enough": gzip e brotli risolvono la maggior parte dei casi.
• CDN moderni: edge caching e HTTP/2/3 hanno spostato il focus.
• Mancato supporto browser: i principali browser non implementano A-IM nativamente.

Dove si usa oggi

Il 226 sopravvive in nicchie specializzate:

• Sistemi di aggiornamento software: alcuni patch system usano vcdiff per delta updates.
• Mobile sync: applicazioni custom su rete cellulare con costi alti.
• Replicazione dati B2B: protocolli proprietari su HTTP che riusano la semantica 226.

Esempio con Delta-Base

GET /api/dataset.json HTTP/1.1
Host: data.example.com
A-IM: vcdiff
If-None-Match: "20260628-1200"

HTTP/1.1 226 IM Used
IM: vcdiff
ETag: "20260629-0800"
Delta-Base: "20260628-1200"
Content-Length: 348

Il client applica il delta vcdiff alla versione cacheata 20260628-1200 ottenendo la nuova versione, da memorizzare con il nuovo ETag.

Quando considerare il 226

Solo in scenari controllati end-to-end (es. app proprietaria con backend dedicato), quando i payload sono grandi (centinaia di KB o più), il rate di modifica e basso e il risparmio di banda compensa la complessita implementativa. Per il web pubblico, attieniti a gzip/brotli e caching tradizionale: e più robusto e universalmente supportato.

Storia del codice

L'RFC 3229 e del 2002. Nasceva in un'epoca in cui la compressione gzip era ancora poco diffusa e le connessioni domestiche erano molto più lente. L'idea di trasferire solo le differenze tra versioni era rivoluzionaria. Tuttavia, la complessita implementativa e il rapido aumento della banda hanno spostato l'industria verso soluzioni più semplici come HTTP/2 con header compression (HPACK) e brotli per body compression.

Differenza con weak ETag

I weak ETag (prefisso W/) indicano equivalenza semantica ma non bit-identità. Sono utili per cache, ma il 226 va oltre: presuppone che client e server condividano una rappresentazione base e siano in grado di applicare trasformazioni deterministiche per arrivare a una nuova versione.

Caso particolare: feeds RSS/Atom

I feed sono un candidato ideale per delta encoding: cambiano poco (un nuovo item ogni tanto) ma vengono polled molto frequentemente. Alcuni aggregatori sperimentali hanno tentato l'uso di 226 con A-IM: feed, dove "feed" significa "mandami solo gli item nuovi rispetto alla versione che ho già". L'idea e poi confluita in protocolli specifici come RSS Cloud e WebSub (PubSubHubbub).

Headers ETag e Delta-Base

Il client per usare il 226 deve memorizzare la versione base e il suo ETag. Il server include Delta-Base: "etag-vecchio" nella risposta 226 per confermare a partire da quale versione e stato calcolato il delta. Se il client ha pulito la cache, dovra fare richiesta normale (senza A-IM) per ottenere full content.

VCDIFF in dettaglio

VCDIFF (RFC 3284) e l'algoritmo standardizzato di delta encoding. Confronta due versioni byte-per-byte e genera istruzioni compatte: COPY (riusa range della versione base), ADD (aggiungi nuovi byte), RUN (ripeti byte). Particolarmente efficace su file con cambiamenti localizzati (es. configurazioni con qualche valore modificato).

Combo: vcdiff + gzip

I delta possono essere ulteriormente compressi: il client invia A-IM: vcdiff, gzip. Server prima calcola il delta vcdiff, poi gzippa il risultato. Per piccole modifiche, il totale puo essere di pochi byte.

Mancata adozione browser

Nessun browser maggiore (Chrome, Firefox, Safari) implementa A-IM nativamente. La ragione: la complessita di mantenere cache delta-aware, la necessità di rollback se la base diverge, l'overhead di gestire ETag chain. La compressione tradizionale e "good enough" nella maggior parte dei casi.

Hai bisogno di aiuto?

Se il tuo sito mostra errori HTTP, il team di G Tech Group puo aiutarti. Contattaci tramite il modulo di contatto.