226

IM Used

El genio del delta encoding que solo te manda los cambios. HTTP optimizado pero que nadie usa. RFC 3229 en toda su gloria.

🔧 Success

📋 ¿Qué narices es esto?

El código 226 IM Used es el "no te mando todo, solo las diferencias" de HTTP. Es cuando el servidor usa delta encoding para enviarte solo los cambios desde la última versión que tienes en caché. Como cuando tu colega programador te dice "aquí tienes el diff" en lugar de enviarte todo el proyecto otra vez.

IM significa "Instance Manipulations" - las transformaciones aplicadas al recurso original. Es una funcionalidad oficialmente estándar desde el RFC 3229 (2002), pero que prácticamente nadie implementa. El cliente envía un header A-IM indicando qué formatos de delta soporta (vcdiff, diffe, gzip), y si el servidor lo entiende, responde con solo los cambios.

El 226 debería aparecer en:

  • Servidores que implementan RFC 3229 (casi ninguno)
  • Sistemas de cache inteligentes con delta encoding
  • APIs que solo devuelven cambios incrementales
  • CDNs con optimización de ancho de banda avanzada
  • Casos donde el contenido cambió pero tienes la versión anterior

🎯 Dato curioso

El 226 es como el Tesla de los códigos HTTP: tecnológicamente brillante, oficialmente estándar, súper eficiente... pero lleva 20+ años esperando que alguien lo adopte masivamente. Es el futuro que nunca llegó.

La idea es genial: en lugar de reenviar una página completa que solo cambió un párrafo, envías el diff usando algoritmos como vcdiff o diffe. El cliente aplica los cambios y reconstruye la versión actual. Perfecto para documentos grandes con cambios pequeños, pero requiere que tanto cliente como servidor soporten delta encoding.

🔧 Cómo implementar esto

🖥️ Para servidores (si quieres ser pionero)

  1. Detecta soporte del cliente: Busca header A-IM en la request.
  2. Verifica versión base: Usa If-None-Match para identificar qué versión tiene.
  3. Calcula delta: Genera diff entre versión base y actual.
  4. Responde 226: Con headers IM y Delta-Base indicando algoritmo.
  5. Incluye solo cambios: Body contiene el delta, no el recurso completo.

📱 Para clientes (si quieres optimizar)

  1. Envía header A-IM: Lista algoritmos que soportas (vcdiff, diffe).
  2. Incluye If-None-Match: ETag de la versión que tienes en caché.
  3. Maneja respuesta 226: Aplica delta a tu versión base.
  4. Reconstruye recurso: Combina base + delta = versión actual.
  5. Actualiza caché: Guarda nueva versión con nuevo ETag.

Problemas típicos con 226

  • Falta de adopción:
    La mayoría de los servidores y clientes no implementan RFC 3229
    Esto limita la efectividad del 226 en la práctica.
  • Compatibilidad limitada:
    Algunos clientes pueden no manejar correctamente los diffs
    Esto podría generar inconsistencias o errores en la interpretación del recurso.

🚀 Respuesta rápida para emergencias

🔥 Si estás implementando 226:
1. Asegúrate de que tanto el cliente como el servidor soporten delta encoding
2. Usa vcdiff o diffe para los algoritmos de delta más comunes
3. Documenta bien los cambios y las expectativas del cliente
🎯 Truco ninja:
Si el cliente no soporta delta encoding, puedes devolver el archivo completo con un 200 OK para no romper la funcionalidad.