Resumen

  • 100 Continue en una Preview ICAP ordena al cliente enviar los bytes encapsulados que faltan; no es el resultado final de adaptación ni la respuesta de un servidor de origen.
  • La prueba debe distinguir bytes de preview, ieof, cuerpo restante, mensaje adaptado, procedencia HTTP, ISTag, caché, autorización y resultado de usuario.

La traza mostraba 100 Continue y luego más datos. El informe dijo que el servidor había aprobado la operación. En realidad, el código lo había emitido un servicio de adaptación que aún no tenía su entrada completa.

ICAP utiliza una sintaxis parecida a HTTP y transporta secciones HTTP encapsuladas, pero no es HTTP ni funciona sobre HTTP. Su 100 pertenece a una conversación entre cliente y servidor ICAP. El origen puede no haber recibido todavía ningún byte de la petición transformada.

RFC 3507 se publicó en abril de 2003 como documento informativo para registrar un protocolo ya utilizado entonces. La nota del IESG recordó que no resolvía las cuestiones arquitectónicas y de política que RFC 3238 había planteado para OPES. El cable describe progreso; no otorga por sí solo el mandato de transformar.

La pausa ocurre dentro del cuerpo encapsulado

El cliente envía todos los encabezados encapsulados y hasta el número de bytes de cuerpo anunciado para Preview. Cierra provisionalmente el flujo de chunks y espera.

El servicio puede decidir que no adapta, devolver un mensaje adaptado o pedir el resto con 100 Continue. La pausa puede estar después de algunos bytes del cuerpo, no solo entre encabezados y cuerpo como en el mecanismo HTTP conocido.

Para interpretar la respuesta hay que conocer la URI ICAP, el método, la longitud solicitada, la longitud real, los offsets de secciones y el estado de lectura del origen. El mismo número sin estas coordenadas es ambiguo.

El consejo histórico de soportar al menos 4096 bytes no dice que 4096 bytes basten para una política concreta. La característica decisiva puede aparecer en el último byte.

El 100 compra evidencia, no concede éxito

Después del 100, el cliente debe continuar desde el primer chunk posterior a la Preview. La adaptación aún puede devolver una modificación, 204 cuando esté permitido, o un error.

Incluso cuando el servicio termina, queda otro salto. En REQMOD, la petición modificada puede dirigirse al origen o a otro adaptador. En RESPMOD, la respuesta modificada debe llegar al consumidor. Ninguno de esos receptores está obligado a aceptar el resultado.

La cadena contiene cuatro verbos distintos: enviar más al adaptador, completar el juicio del adaptador, presentar el objeto al siguiente HTTP y obtener un efecto de aplicación. 100 solo satisface el primero.

La métrica correcta no es “operaciones aprobadas por 100”, sino “solicitudes de cuerpo restante”, segmentada por Preview, servicio y resultado final.

ieof elimina la posibilidad de pedir más

El cliente puede estar retransmitiendo una respuesta de longitud desconocida. Si el origen termina durante la Preview, ICAP añade la extensión ieof al chunk final.

El servicio sabe entonces que la Preview contenía el final real. Debe responder con un resultado modificado o 204; no puede enviar 100 Continue. El marcador se elimina antes de entregar los bytes al proceso de adaptación.

Guardar solo el buffer de aplicación elimina la prueba de que el fin ocurrió durante la Preview. Guardar solo la captura no explica qué bytes recibió el motor después de retirar el framing. Se necesitan ambas vistas.

Que ieof no aparezca tampoco garantiza que el resto llegue. La conexión con el origen puede cerrarse después, dejando una invitación a continuar sin datos que enviar.

204 usa el original que conserva el cliente

Durante Preview, 204 No Content permite tratar el mensaje como si el servicio hubiera devuelto una copia idéntica. El ahorro funciona porque el cliente retuvo la porción adelantada y conserva acceso al resto.

Fuera de Preview, el cliente puede declarar Allow: 204. Sin esa declaración, el servicio debe devolver el mensaje completo aunque no lo modifique. La restricción protege una capacidad del cliente, no un significado de seguridad.

204 no significa que el contenido sea limpio, auténtico o autorizado. Significa que no se devolvió una adaptación bajo ese intercambio. La frase “no quiere o no puede modificar” deja más de una causa posible.

El recibo debe mostrar buffer, reconstrucción y hash del original reanudado. De otro modo, el estatus oculta una posible pérdida de bytes.

Un error HTTP puede nacer antes del origen

En REQMOD, el servicio ICAP puede devolver una respuesta HTTP de error en lugar de una petición modificada. Ese error tiene procedencia del camino de adaptación. No prueba que el origen evaluara la petición.

Esta distinción importa para auditoría, reintentos y responsabilidad. Reenviar automáticamente contra otro adaptador puede evitar una política local; culpar al origen puede dirigir la reparación al equipo equivocado.

En RESPMOD, una respuesta del origen puede transformarse antes de llegar al usuario. El objeto final debe vincularse al original y a cada servicio intermedio.

Conservar solo el último estatus HTTP borra quién lo creó. La encapsulación proporciona la oportunidad de mantener esa procedencia; no la impone al registro de negocio.

ISTag delimita la configuración que decidió

Cada respuesta ICAP debe incluir un ISTag. El token representa un estado del servicio y permite invalidar resultados en caché cuando cambia software, configuración o datos de decisión.

Su alcance es de servicio, no de una sola entidad. Un cambio puede afectar muchos objetos asociados a la URI ICAP. Pero el token no demuestra qué reglas contiene ni que todos los nodos de un clúster compartan la misma versión.

La evidencia asocia tag, manifiesto, despliegue, nodo, hora y acción de invalidación. Si un nodo continúa emitiendo la época antigua, una caché puede reutilizar una decisión que el control central cree retirada.

El tag es un identificador de comparación, no una firma ni un certificado del contenido.

OPTIONS no vive para siempre

OPTIONS anuncia métodos, tamaño de Preview, Allow, listas de transferencia, capacidad, duración y ISTag. La respuesta puede expirar.

La entrada adaptada tiene su propia vida de caché. En RESPMOD, su expiración no puede superar la del objeto de origen, aunque puede ser menor. El estado de servicio puede cambiar en un tercer reloj.

Una transacción basada en OPTIONS vencido quizá envíe una Preview inadecuada o suponga soporte que ya no existe. Un resultado todavía fresco según HTTP puede quedar obsoleto por un nuevo ISTag.

El registro debe conservar las tres edades en el momento de la decisión, no solo el valor actual consultado después.

Los offsets de encapsulación describen el mapa

El encabezado Encapsulated indica dónde empiezan encabezados y cuerpos de petición o respuesta, el cuerpo OPTIONS o el cuerpo nulo. Hace posible separar las piezas del mensaje compuesto.

Los offsets no validan la semántica HTTP. Tampoco prueban que una transformación preserve referencias, firmas, política de caché o intención del usuario.

El framing por chunks, el cierre de Preview, ieof, el estado ICAP y el estado HTTP son capas distintas. Una reserialización puede cambiar el mapa y debe quedar como transformación, no como copia invisible.

La política de adaptación necesita un propietario

RFC 3238 y los textos OPES posteriores tratan consentimiento, notificación, privacidad, reglas, dominios de confianza y trazabilidad. Ofrecen el contexto que ICAP por sí solo no suministra.

Una regla debe decir quién delegó al adaptador, para qué flujo, con qué límites y cómo se registra la modificación. La autenticación del canal ICAP no demuestra consentimiento del productor o consumidor.

El resultado de protocolo y la autoridad de política deben encontrarse en la auditoría, pero no fundirse.

La secuencia correcta de recibos

Empiece por el HTTP original, su rol y punto de captura. Identifique recurso y método ICAP, identidades, OPTIONS, caducidad y ISTag. Valide offsets.

Registre Preview pedida y real, ieof, lectura de origen y buffer. Después guarde 100 o resultado final, cuerpo restante y bytes vistos por el servicio.

Para modificar, guarde antes/después y regla. Para cachear, clave, frescura y tag. Para 204, reconstrucción exacta.

Solo después llegan el siguiente salto HTTP, la procedencia del origen, la entrega, la autorización y el resultado autenticado de la aplicación.

Límite de la evidencia

Este artículo no describe un producto, proxy, scanner, despliegue o incidente actual. No afirma que 100 o Preview sean defectuosos. Define su alcance.

Tampoco repite la historia de HTTP 100 Continue, que estudia permiso para gastar el cuerpo en la frontera HTTP. Aquí el objeto es una llamada de adaptación con cuerpo encapsulado y procedencia separada.

La especificación inicial mínima y la primacía del código en ejecución de Heng Lu son lentes editoriales declaradas. Favorecen un contrato compartido estrecho y pruebas del flujo real; no miden adopción.

El veredicto es sencillo: cuando ICAP dice 100, todavía está reuniendo la pregunta. No ha contestado la operación.

Sources