Resumen

  • RFC 2295 hizo visibles en una lista legible por máquinas las distintas representaciones asociadas a un URI HTTP, pero una respuesta de lista no incluía datos de ninguna variante.
  • La selección, la recuperación y la presentación seguían siendo pasos separados: el servidor podía responder con una variante elegida bajo ciertas condiciones y el cliente también podía elegir y solicitar una de las anunciadas.

Un recurso podía tener más de una respuesta

A finales de los años noventa, la Web ya afrontaba una discrepancia práctica. Un recurso podía existir en HTML o PostScript, en inglés o francés, con requisitos distintos según el programa que lo consultara. El editor podía publicar URL separadas o negociar entre versiones bajo un solo URI. El reto no consistía únicamente en escoger una versión: los intermediarios, sobre todo las cachés, también debían distinguir qué respuesta correspondía a cada solicitud.

RFC 2295, «Transparent Content Negotiation in HTTP», propuso un mecanismo experimental para hacer visibles las alternativas. El memorando de marzo de 1998 llamó variante a cada versión y describió una lista legible por máquinas vinculada a un recurso negociable. El encabezado Alternates podía asociar a cada candidata su URI y atributos como el tipo de medio, el idioma, la calidad de origen o ciertas características. «Transparente» quería decir que las variantes alojadas en el servidor de origen quedaban visibles para terceros; no significaba que todos los navegadores negociaran de forma automática ni que la elección desapareciera.

El mecanismo definía cuatro dimensiones: tipo de medio, juego de caracteres, idioma y características. Esta última permitía expresar propiedades que las tres primeras no cubrían, como determinadas extensiones de HTML o capacidades de un formato. La codificación del contenido —por ejemplo, la compresión— era ortogonal, no una quinta dimensión de variantes. La distinción importa: el documento describía qué representación podía resultar adecuada, no todas las transformaciones que el servidor pudiera aplicar a sus bytes.

Tres comprobantes, no un solo evento

La respuesta de lista era un inventario. RFC 2295 la define como una respuesta que devuelve la lista de variantes, pero no sus datos. Un agente de usuario compatible podía evaluar las alternativas y recuperar una mediante una solicitud HTTP normal a su URI. El ejemplo de la RFC separa literalmente las operaciones: el servidor entrega primero la lista; después el cliente solicita paper.1; la segunda respuesta es la que contiene el documento. Una respuesta 300 Multiple Choices también podía incluir un cuerpo legible para que una persona eligiera manualmente, incluso con un agente que no negociaba. Aun así, la lista no era la representación seleccionada.

El servidor no quedaba limitado a catalogar. Una choice response devolvía una representación de la mejor variante y podía incluir también la lista. Pero el servidor necesitaba información suficiente para elegir en nombre del agente, y la variante debía cumplir la regla de proximidad entre recursos definida por la RFC. RFC 2296, el memorando experimental complementario, especificó un algoritmo de selección remota y condicionó esa respuesta: si la evidencia no establecía una mejor variante positiva y determinada, o no se cumplía la condición de proximidad, el algoritmo devolvía una lista. El cliente podía aplicar su propio algoritmo y, cuando la lista seguía disponible, recuperar una opción distinta.

Por eso no es exacto resumir la historia diciendo «el cliente elegía». A veces podía hacerlo; otras, el servidor. El protocolo distinguía el inventario de candidatas, la autoridad que tomaba la decisión, la respuesta que transportaba los bytes y la presentación posterior. Desde la perspectiva del servidor, el encabezado Negotiate indicaba que el agente declaraba ser compatible con la negociación transparente. Esa declaración de capacidad no demuestra que una solicitud concreta la utilizara.

La caché formaba parte del diseño

La negociación puede hacer que un mismo URI produzca representaciones distintas. Si una caché las confunde, hasta un buen algoritmo de selección dará un resultado equivocado. Por eso RFC 2295 se apoyó en Vary y en etiquetas de entidad, y añadió validadores para las listas de variantes. También describió cómo una caché podía extraer una respuesta HTTP normal de una respuesta de elección y cómo se relacionaba la ubicación del recurso elegido con el recurso negociable. La corrección de la caché no era fontanería secundaria: formaba parte del contrato que hacía viable reutilizar un URI.

Ese diseño tenía un coste. Enviar todas las preferencias en cada solicitud podía alargar los encabezados, de modo que el agente a menudo necesitaba inspeccionar la lista localmente. Pero las preferencias Accept pueden revelar rasgos del software o del entorno de una persona. El memorando abordó expresamente la fuga de información privada, la suplantación de respuestas procedentes de variantes y los problemas de seguridad que la negociación podía revelar. Son riesgos reconocidos en el diseño, no pruebas de que ocurriera un incidente concreto.

RFC 2295 era explícitamente Experimental y afirmaba que no especificaba ninguna norma de Internet. Su mecanismo transparente se aplicaba a GET y HEAD, no a todas las transacciones HTTP. El texto permite reconstruir una ambición: mostrar las alternativas y repartir la decisión entre clientes, servidores y cachés. Las fuentes aquí consultadas no acreditan un censo de compatibilidad de navegadores, una tasa de despliegue ni un resultado para usuarios. Una variante anunciada no necesariamente se recuperó; recibir una respuesta tampoco demuestra qué llegó a ver una persona.

Fuentes