Resumen

  • El RFC 2965 de octubre de 2000 diseñó una negociación: un cliente compatible con cookies antiguas y nuevas debía conservar el envío de Cookie cuando correspondiera y anunciar Cookie2: $Version="1". Un servidor que entendiera la versión nueva debía proseguir con Set-Cookie2; uno antiguo podía ignorar el anuncio.
  • Set-Cookie2 permitía un atributo Port para restringir los puertos de retorno y un CommentURL para ofrecer información al usuario. El aviso del cliente, la respuesta del servidor y una eventual decisión humana eran hechos separados.
  • El RFC 6265 de abril de 2011 sustituyó el RFC 2965, pidió clasificarlo como histórico y abandonó Cookie2 y Set-Cookie2. Definió los campos Cookie y Set-Cookie tal como se usaban en Internet y señaló que las cookies de un host se comparten entre puertos.

Una credencial para hablar otro dialecto

Los servidores querían relacionar una petición HTTP con la siguiente. Entregaban una cookie al navegador, que la devolvía cuando procedía. El RFC 2109 de febrero de 1997 ya había descrito una versión de ese intercambio. Para mejorarla había un obstáculo evidente: miles de programas seguían hablando las versiones anteriores. Nadie podía actualizar simultáneamente cada navegador y cada servidor.

El RFC 2965 de octubre de 2000 propuso una transición con dos carriles. En la respuesta, el servidor nuevo disponía de Set-Cookie2. En la petición, el navegador podía añadir Cookie2 para informar de su capacidad. Un cliente que entendiera tanto la especificación nueva como las cookies antiguas debía seguir devolviendo un Cookie de la manera anterior cuando ese valor hubiera llegado mediante Set-Cookie. También debía enviar Cookie2: $Version="1". El mensaje extra invitaba al servidor a usar el dialecto nuevo.

El servidor preparado debía continuar la sesión con Set-Cookie2; el servidor que no conocía el campo podía ignorarlo. La parte vieja del intercambio seguía operando. Era una forma elegante de evitar que una mejora derribara de golpe las sesiones de quienes aún no se habían actualizado.

Conviene distinguir los papeles. Cookie2 no era el nuevo recipiente de todos los valores de sesión. Era un aviso sobre la versión entendida por el cliente. Set-Cookie2 llevaba valores y atributos del servidor al navegador. Después, el navegador devolvía las cookies aplicables en Cookie, bajo las reglas que correspondieran. La negociación, la emisión de estado y su retorno eran tres recibos diferentes.

Una cabecera Cookie2 aislada en una captura mostraría lo que el navegador decía poder hacer. Para saber si el servidor aceptó la oferta habría que encontrar su respuesta; para saber qué estado regresó después habría que mirar la siguiente petición. El protocolo podía invitar a un cambio, pero el anuncio por sí solo no ejecutaba la migración.

Lo que el carril nuevo ofrecía

La nueva respuesta tenía atributos con consecuencias concretas. Port permitía acotar el envío posterior. Sin el atributo, una cookie podía volver a cualquier puerto del host correspondiente. Con Port presente sin valor, debía volver solo al puerto donde se había recibido. Si llevaba una lista, solo podían recibirla los puertos enumerados. Era una manera de expresar una frontera más estrecha entre servicios que compartían máquina.

CommentURL ofrecía otra clase de control: una dirección donde explicar para qué se usaba la cookie. El texto prefería una página de explicación porque podía contener más información e idiomas que un comentario breve. La especificación quería que el servidor ayudara a informar al usuario. La existencia de la dirección abría esa posibilidad; la lectura y la decisión de la persona requerían actos posteriores.

Por eso la actualización tenía más sustancia que el número 2 añadido al nombre de una cabecera. Prometía una restricción por puerto, una vía de explicación y un modo de descubrir si el otro extremo estaba listo. Para obtener esos beneficios debían coincidir clientes y servidores que entendieran los nuevos campos. Las características de un carril vacío no llegan a la sesión que continúa por el antiguo.

La compatibilidad ocupaba mucho espacio en el RFC. Un navegador viejo, ajeno a Set-Cookie2, seguía con el estilo de cookies que conocía. Uno capaz de hablar ambos estilos tenía que recordar cómo había recibido cada valor y responder de acuerdo con ello. Si una respuesta contenía las dos cabeceras para una cookie equivalente, el agente compatible debía dar prioridad a la nueva. La protección de las sesiones existentes se pagaba con software capaz de sostener dos reglas a la vez.

Las especificaciones consultadas no ofrecen un recuento de navegadores que enviaron Cookie2 ni de servidores que devolvieron Set-Cookie2. Versiones fechadas y trazas de intercambio permitirían reconstruir esa adopción. Los textos oficiales sí dejan claro cómo se diseñó la oferta y qué decidió el siguiente estándar sobre ella.

El estándar de 2011 elige el tráfico que había

El RFC 6265 de abril de 2011 cambió el punto de partida. Definió Cookie y Set-Cookie según su uso real en Internet. Su introducción explica que las descripciones previas, incluidas las de RFC 2109 y RFC 2965, no retrataban adecuadamente ese uso. A los servidores les recomendó un perfil cuidadoso al emitir cookies; a los clientes les asignó reglas de lectura más permisivas para entender respuestas ya presentes en la red. La norma salió a encontrarse con el software desplegado.

En el mismo tramo, pidió trasladar las dos especificaciones anteriores a la categoría histórica, sustituyó el RFC 2965 y desaprobó expresamente Cookie2 y Set-Cookie2. La sección de registro de cabeceras marca ambos nombres como obsoletos. La tarjeta que anunciaba la capacidad nueva y la respuesta diseñada para ella quedaban fuera del contrato central. Permaneció el intercambio ordinario que los sitios seguían usando.

El texto de 2011 no retrata ese intercambio como una obra perfecta. Señala que las cookies de un mismo host se comparten entre sus puertos, aunque la política de origen de los navegadores separa normalmente contenido cargado desde puertos distintos. Esa es precisamente una frontera para la que Port había ofrecido una elección más estrecha en 2000. El estándar posterior describió la práctica existente y dejó la restricción versionada en la rama retirada.

La decisión documental es comprobable: RFC 2965 quedó sustituido y los dos campos se declararon obsoletos. Una cronología por navegador sobre quién implementó o dejó de implementar Cookie2 necesita archivos de versiones y registros de desarrollo. El contraste entre los RFC, en cambio, basta para ver el giro: la mejora negociada fue propuesta como camino futuro en 2000; en 2011, la conversación más sencilla volvió a ocupar el centro.

La salida de emergencia acaba siendo la autopista

El diseño de 2000 era paciente. El navegador anunciaba su capacidad; el servidor respondía si la compartía; el participante antiguo continuaba por la vía conocida. Esa paciencia evitaba la rotura inmediata. También hacía que cada beneficio de la versión nueva dependiera de la presencia de ambos participantes. Un servidor podía esperar a que hubiera navegadores; un navegador podía esperar a que hubiera servidores.

Cuando la especificación de 2011 eligió Cookie y Set-Cookie, la historia no se redujo a una preferencia estética. Los campos antiguos tenían aplicaciones construidas a su alrededor. La nueva norma hizo explícitas algunas de sus carencias, incluido el alcance entre puertos. Las ventajas de Port y CommentURL quedaron registradas en un camino que el nuevo texto retiraba.

Una mejora puede resolver un problema real y ofrecer una transición amable. Si el camino de reserva permite seguir trabajando, también puede convertirse en el camino permanente. Cookie2 fue la invitación protocolaria. Once años después, HTTP archivó la invitación y escribió las normas para los invitados que de verdad estaban en la sala.