Resumen

  • RFC 9110 define Via como un registro ordenado de proxies y pasarelas HTTP que reenviaron un mensaje concreto; las entradas pueden usar seudónimos y, en condiciones limitadas, agruparse.
  • Afirmar que una ruta está completa exige unir los campos exactos de solicitud y respuesta con registros de entrada y salida, configuración, túneles, capas inferiores, transformaciones y tiempos.

Imagine una revisión de incidente en la que una solicitud llega con dos miembros Via. El panel convierte esas dos entradas en un diagrama y afirma que solo dos intermediarios participaron en el reenvío. Sin embargo, un portal de cortafuegos ocultó varios nombres internos tras un seudónimo, dos pasarelas del mismo operador combinaron entradas del mismo protocolo, un túnel transportó bytes sin seguir siendo participante HTTP y una redirección de capa inferior nunca apareció en el campo.

El caso es hipotético y no describe a ningún proveedor. Sirve para mostrar un error de evidencia: leer un campo de protocolo fuera del alcance de los actores y reglas de divulgación que lo generaron.

RFC 9110 distingue proxy, pasarela y túnel. El proxy es elegido por el cliente y reenvía mensajes. La pasarela se presenta como servidor de origen hacia fuera y traduce o reenvía hacia dentro. El túnel se convierte en un relevo ciego entre dos conexiones y, una vez activo, deja de ser parte de la comunicación HTTP. También existen dispositivos de capas inferiores que filtran o redirigen tráfico sin conocimiento de los emisores HTTP. Su influencia no produce una entrada Via.

El campo sí cumple una función precisa. En una solicitud indica protocolos y receptores intermedios entre agente de usuario y servidor; en una respuesta, entre servidor de origen y cliente. Cada miembro representa un proxy o una pasarela que reenvió ese mensaje. received-protocol registra la versión de protocolo empleada por el emisor anterior, mientras que received-by identifica al receptor, sujeto a seudonimización. El orden resultante ayuda a evitar bucles, seguir reenvíos y conocer las capacidades de protocolo anunciadas por los emisores anteriores.

Las obligaciones son asimétricas y un mismo intermediario puede cambiar de función entre solicitudes. Cuando actúa como proxy debe añadir un Via apropiado a cada mensaje que reenvía. Cuando actúa como pasarela HTTP a HTTP, y no como túnel activo, debe añadirlo a las solicitudes entrantes, mientras que en las respuestas reenviadas su inclusión es opcional. Al pasar a funcionar como túnel activo deja de ser parte de la comunicación HTTP. La lista de la respuesta no tiene por qué reflejar la de la solicitud. Comparar cantidades sin dirección, identidad del mensaje, función efectiva y punto de captura inventa una simetría que la norma no garantiza.

received-by tampoco es un inventario estable. Normalmente contiene host y puerto opcional, pero puede sustituirse por un seudónimo cuando revelar el host sea sensible. Un portal en un cortafuegos debe ocultar nombres internos salvo habilitación explícita. Los comentarios de software son opcionales y pueden eliminarse. Como Via no está autenticado, un token es una declaración de reenvío; la participación exige corroboración mediante captura fiable e integridad. Por sí solo no identifica una dirección enrutable, un proceso ni una entidad operadora.

Hasta la longitud necesita contexto. RFC 9110 solo permite combinar una subsecuencia ordenada cuando sus miembros comparten el mismo received-protocol; aun entonces, el emisor debería abstenerse si esos miembros no están además bajo el mismo control organizativo o si sus hosts todavía no han sido sustituidos por seudónimos. No se pueden combinar protocolos recibidos diferentes. Considerados en conjunto, estos requisitos conservan la frontera de capacidad del protocolo y solo permiten comprimir una topología interna controlada y seudonimizada. Un miembro visible puede resumir varios intermediarios.

Las transformaciones pertenecen a otro plano de prueba. Un proxy puede modificar campos o contenido. Una pasarela puede traducir entre HTTP y un protocolo privado. Un túnel puede transportar bytes cifrados sin revelar mensajes ni todos los relevos. Via registra participación en el reenvío HTTP, pero no atribuye por completo cambios, caché, controles de seguridad, equilibrado ni enlaces físicos.

Un recibo de custodia del mensaje debe conservar la identidad exacta de solicitud y respuesta, los valores Via sin normalizar en cada captura, versión y dirección del protocolo, relación entre seudónimo e intermediario controlado, reglas de combinación, tiempos de entrada y salida, caché, transformaciones, extremos de túnel y observaciones inferiores. “No visible en Via” debe diferenciarse de “ausente de la ruta”. El recibo es una síntesis operativa editorial, no un objeto de protocolo de la IETF.

La frontera también separa este trabajo de los cercanos. Las direcciones IPv6 temporales tratan la correlación tras rotar un identificador. BFD trata vivacidad acotada y decisión de ruta. HTTP Priority trata el resultado de una preferencia de planificación. Via trata procedencia y completitud del registro de reenvío.

Fuentes