Resumen

  • En 1994, marketplaceMCI necesitaba conservar datos de pedidos, facturación y envío entre solicitudes web. MCI descartó la propuesta inicial de Netscape de guardar el estado en el servidor y exigió almacenarlo en el cliente.
  • Netscape convirtió ese requisito en una función general del navegador. Un servidor podía enviar un valor de estado para que el navegador lo devolviera en solicitudes posteriores dentro de cierto alcance; ese valor no identificaba por sí solo a quien tenía el navegador.
  • RFC 2109 intentó formalizar después un mecanismo que el código y la compatibilidad ya habían moldeado. Sus reglas reconocían los límites del control del usuario, la legibilidad de los valores y el transporte sin protección.

Una cesta convirtió el olvido del protocolo en un problema de producto

El patrón habitual de petición y respuesta de la Web tenía una carencia práctica. Una solicitud HTTP pedía un recurso y recibía una respuesta, pero la siguiente no arrastraba automáticamente el historial de la aplicación. Un comerciante podía conservarlo en su servidor, aunque así debía gestionar el estado y los registros que quedaban cuando el navegador desaparecía.

MCI preparaba marketplaceMCI, un entorno de compras en línea con un navegador de marca MCI, un servidor web, servidores de comerciantes que recibirían y completarían pedidos, y sistemas internos para asistencia y cuentas comerciales. La tarea era específica: hacer circular información de pedidos, facturación y envío a través de varias solicitudes.

La decisión de diseño aparece en un expediente judicial posterior, no en una leyenda sobre un inventor aislado. En una reunión del 10 de agosto de 1994, MCI rechazó la propuesta inicial de Netscape de mantener el estado en un servidor. Exigió que la información se almacenara en el ordenador cliente. La resolución presenta ese requisito general como no controvertido, aunque conserva desacuerdos sobre algunos detalles técnicos.

El requisito trasladó la memoria temporal de la aplicación. El navegador conservaría un objeto pequeño entre intercambios con el servidor. Lou Montulli, programador de Netscape, recibió el encargo. Recordaba que en el verano le pidieron un método de cesta que resolviera la naturaleza sin sesión de HTTP, aunque no recordaba a MCI como cliente concreto. Marc Andreessen declaró que el proyecto de MCI acabó dando lugar a las cookies y que Netscape amplió la función para uso general. Los testimonios conectan la necesidad del cliente con una decisión de producto sin convertir cada detalle del diseño en una certeza.

El navegador pasó a transportar el estado de la aplicación

La copia conservada de la especificación de Netscape describe el mecanismo de forma sencilla. Un servidor podía adjuntar un objeto de estado a una respuesta HTTP. El navegador lo guardaba y lo incluía en solicitudes posteriores cuyas URL coincidieran con el alcance de la cookie. La aplicación del servidor elegía el valor y lo interpretaba; el navegador lo retenía y lo devolvía.

Así, una referencia a una cesta, un dato de registro o una preferencia podía atravesar varias solicitudes. HTTP no se convirtió en un protocolo con conexión continua. Tampoco era necesario insertar la cesta individual de cada visitante dentro de cada página, algo relevante para las cachés web. Y el servidor no dejaba de intervenir: podía emplear el valor recibido como clave para datos guardados en otro lugar.

El documento de Netscape se describía como una especificación preliminar y pedía cautela. Sus reglas iniciales delimitaban el host o dominio, la ruta, la caducidad y la transmisión segura. Esos límites indicaban cuándo el navegador devolvería el estado. No probaban el nombre de una persona, su consentimiento ni que siguiera presente.

La resolución sitúa código preliminar de cookies en el repositorio de Netscape el 3 o 4 de octubre de 1994, con cambios posteriores el 6 y el 13 de octubre. Las partes del litigio discutían la fecha exacta de reducción a la práctica. La cronología prudente es, por tanto, una necesidad del cliente y un diseño durante el verano, código a principios de octubre según el expediente y la conversión de la función en una capacidad general del navegador. No hay un único día de invención aceptado por todos.

El estándar llegó después de la propuesta del navegador

En febrero de 1997, David Kristol y Montulli publicaron RFC 2109, «HTTP State Management Mechanism». El documento describía respuestas Set-Cookie y solicitudes Cookie, e intentaba fijar su gramática. También incluía una sección histórica para la compatibilidad con la propuesta original de Netscape. Estandarizar significaba acomodar código y comportamientos que ya circulaban.

RFC 2109 exponía los límites del mecanismo. El agente de usuario debía ofrecer a las personas control sobre el envío y la conservación de cookies. Los encabezados viajaban sin protección, por lo que un valor sensible podía quedar expuesto o ser alterado. El valor era opaco para el navegador, pero podía ser legible. En el ejemplo de inicio de sesión, la persona se identifica primero mediante un formulario; después, el servidor devuelve una cookie que refleja esa identidad. La cookie prolonga el estado de la aplicación tras ese paso. No constituye una comprobación de identidad independiente.

La diferencia importa porque un valor guardado en el navegador puede ser útil para un servicio sin demostrar quién lo controla. Si una aplicación trata la posesión del valor como autoridad, crea una capacidad de sesión al portador. Quien consiga el valor podría reutilizarlo dentro de su alcance y vigencia. La seguridad depende de cómo se emite, protege, caduca y revoca; el intercambio básico de cookies no resuelve esas decisiones.

La importancia histórica de la cookie es menos misteriosa que su nombre. Un flujo de compra obligó a un equipo de producto a elegir dónde residiría la continuidad. El navegador pasó a llevar un estado elegido por el servidor; una necesidad de un cliente se convirtió en una función reutilizable; y un estándar posterior registró la compatibilidad con la práctica desplegada. Las aplicaciones web podían así recordar una transacción entre solicitudes separadas. El navegador nunca se convirtió en testigo de la identidad humana que había detrás.

Fuentes y límites