Protocolo de adaptación de contenido de Internet

El Protocolo de Adaptación de Contenido de Internet ( ICAP ) es un protocolo ligero similar a HTTP especificado en RFC  3507, que se utiliza para ampliar los servidores proxy transparentes , liberando así recursos y estandarizando la forma en que se implementan nuevas funciones. ICAP se utiliza generalmente para implementar escaneo de virus y filtros de contenido en cachés de proxy HTTP transparentes. La adaptación de contenido se refiere a la realización del servicio de valor agregado particular (manipulación de contenido) para la solicitud/respuesta del cliente asociada.

ICAP se concentra en aprovechar los dispositivos basados ​​en el borde ( proxies de almacenamiento en caché ) para ayudar a brindar servicios de valor agregado . En el centro de este proceso se encuentra un caché que hará de proxy de todas las transacciones del cliente y las procesará a través de servidores web . Estos servidores ICAP se centran en una función específica, por ejemplo, inserción de anuncios, escaneo de virus , escaneo de múltiples antivirus, traducción de contenido, traducción de idioma o filtrado de contenido . La descarga de servicios de valor agregado de los servidores web a los servidores ICAP permite que esos mismos servidores web se escalen de acuerdo con el rendimiento HTTP sin procesar en lugar de tener que manejar estas tareas adicionales.

ICAP fue propuesto a finales de 1999 por Peter Danzig y John Schuster ^[1] de Network Appliance . ^[2] Don Gillies se hizo cargo del proyecto en la primavera de 2000 y mejoró el protocolo de tres maneras principales:

• Para permitir servidores ICAP canalizados, una página web podría transmitirse rápidamente a través de servidores de escaneo de virus, filtrado de contenido y traducción de idiomas.
• Para admitir las tres codificaciones de contenido (longitud de contenido, fragmentación y TCP-close) en HTTP 1.1. Esto reemplazó el protocolo original de almacenamiento y reenvío con transmisión continua de contenido a través de muchos servidores a la vez.
• Proporcionar una función denominada "vista previa de contenido" que permitiera al servidor ICAP ver los primeros cientos de bytes de contenido antes de decidir si procesarlo o no. Esto se implementó incorporando el tamaño del argumento de vista previa en la URL del servidor web ICAP cuando se configuró en el cliente ICAP.

Gillies diseñó el primer cliente y servidor ICAP para la serie NetCache de cachés de Internet a mediados de 2000 (conocido como protocolo ICAP 0.9) y produjo materiales de capacitación para los proveedores. El cliente se escribió en C++ en el núcleo del servidor NetCache, y el servidor ICAP de demostración se escribió en Perl y empleó los filtros de reemplazo de palabras de Debian para reescribir páginas web, salteando las etiquetas HTML y traduciendo páginas web a Swedish Chef o Jive en tiempo real. ^[3] Con el conocimiento adquirido en la experiencia de creación de prototipos, Gillies revisó el borrador del estándar IETF para hacer RPC utilizando solo codificación fragmentada, simplificando enormemente el protocolo ICAP. ^[1]

• RFC  3507
• Foro ICAP
• Una página de ICAP Beta Testing traducida de Yahoo News a Jive! (20 de septiembre de 2000)