Resumen

  • RFC 10025 exige cautela al productor y tolerancia al consumidor. Una línea Set-Cookie bien formada todavía puede ser ignorada, rechazada, normalizada, sustituida o expulsada del almacén del agente de usuario.
  • Guardar no equivale a enviar, y enviar no equivale a autorizar. El control útil enlaza cada veredicto mediante identificadores opacos sin copiar el valor de la cookie ni el secreto de sesión.

El síntoma aparece después de un cambio aparentemente banal. La respuesta de inicio de sesión contiene Set-Cookie; la sonda de red la captura; el panel marca la operación como correcta. En la navegación posterior no llega ninguna cookie. En otra petición llegan dos con el mismo nombre.

Ninguno de esos hechos demuestra por sí solo una pérdida en la red. El agente de usuario pudo rechazar la instrucción, aceptar una fila con un ámbito distinto, reemplazar una fila anterior, eliminarla al cerrar la sesión o no seleccionarla para el contexto posterior. El servicio conoce su emisión. La vida de la cookie ocurre bajo otra autoridad.

RFC 10025, publicado por la IETF en julio de 2026 como Standards Track y sucesor de RFC 6265, describe esa arquitectura. Set-Cookie entrega nombre, valor y atributos. El campo Cookie de una solicitud posterior devuelve pares seleccionados. No devuelve la política aplicada, el estado normalizado ni el motivo de inclusión.

La asimetría es deliberada

El texto separa a quienes producen cookies de quienes las consumen. El productor debería limitarse a un perfil estricto y predecible. El consumidor debe interpretar un conjunto más amplio para convivir con servidores existentes que no cumplen ese perfil. Es un pacto de interoperabilidad, no una prueba de que ambos lados compartan el mismo objeto.

Por eso un validador del servidor solo puede afirmar que la instrucción emitida es aceptable. No conoce el motor del cliente, la versión de su política, el origen y contexto efectivos ni la rama del algoritmo que se ejecutará. Al comenzar el procesamiento, el agente de usuario incluso puede ignorar por completo la cookie recibida.

La etiqueta «cookie instalada» borra responsabilidades. El equipo de aplicación redacta la instrucción; la pila HTTP conserva las líneas; el agente de usuario interpreta; el usuario o administrador puede restringir la política; el contexto de una navegación o un worker decide la selección; la aplicación receptora valida la sesión y autoriza el recurso.

De texto recibido a estado normalizado

El algoritmo rechaza caracteres de control, pares cuyo nombre y valor exceden el límite, dominios no admisibles y combinaciones que contradicen atributos o prefijos. SameSite=None sin Secure no entra en el almacén. Los prefijos __Secure- y __Host- solo reciben sus garantías si se cumplen las condiciones correspondientes, y el consumidor compara esos prefijos sin sensibilidad a mayúsculas.

La fila aceptada contiene más que el par visible: caducidad efectiva, dominio, ruta, horas de creación y último acceso, y banderas de persistencia, solo-host, canal seguro, HttpOnly y SameSite. Max-Age prevalece sobre Expires. La falta de Domain crea una cookie solo para el host. Nombre, dominio y ruta juntos determinan si una fila nueva sustituye a otra.

Un encabezado y una ausencia posterior dejan abiertas demasiadas hipótesis. Hace falta registrar la huella de la instrucción, la decisión de admisión y la forma normalizada. Así se distingue un rechazo sintáctico de una regla de privacidad, una sustitución válida de una actualización rechazada y una fecha pedida de una fecha realmente aplicada.

La fecha límite no garantiza permanencia

El servidor propone un máximo. El cliente no promete custodia hasta ese instante. Puede limitar la duración, eliminar lo caducado, expulsar entradas por topes locales, atender una eliminación del usuario o borrar filas no persistentes cuando termina la sesión según su propia definición. RFC 10025 aconseja a los servidores degradar con gracia porque cualquier cookie puede desaparecer antes de lo previsto.

Por tanto, «Expires dentro de un año» no prueba que el estado sobrevivirá un año. El dato operativo es el evento de conservación: vencimiento efectivo, reemplazo, borrado, fin de sesión, exceso de cuota o limpieza de política. En clientes administrados puede observarse localmente. En el navegador de un visitante, exigir el historial completo sería desproporcionado. Bastan motivos agregados o diagnósticos expresamente consentidos.

Cada recuperación vuelve a aplicar la política

La existencia de una fila no obliga a enviarla. La recuperación evalúa URI, condición de mismo sitio y tipo de acceso. Excluye por caducidad, host o dominio, ruta, canal inseguro, HttpOnly o SameSite. Además, el agente de usuario puede omitir por completo Cookie de acuerdo con su política.

El estándar Fetch incluye las cookies entre las credenciales del proceso web. La superficie document.cookie de HTML es una API no HTTP y no atraviesa las mismas fronteras. Documentos anidados, recargas, navegaciones y workers cambian el contexto que se usa para calcular el «sitio para cookies».

SameSite tampoco es una autorización. Strict, Lax, None y Default producen efectos condicionados por el tipo de navegación y la historia del documento. El modo de compatibilidad Lax-allowing-unsafe puede usar una ventana reciente definida por el agente de usuario. El RFC presenta SameSite como defensa en profundidad, no como protección general contra CSRF, y recuerda que lo elige el servidor, no la persona usuaria.

El servidor recibe un par, no su expediente

La solicitud no reenvía Domain, Path, SameSite, tiempo de creación ni causa de selección. Puede contener dos filas con el mismo nombre y ámbitos distintos. El servidor no debería convertir el orden de serialización en una prioridad semántica. HTTP/2 y HTTP/3 permiten que una cadena lógica se transporte en más de una línea sin que eso aporte el historial ausente.

Después viene otra frontera. La aplicación analiza la cadena, busca la sesión, comprueba caducidad o revocación, autentica una identidad y decide si esa identidad puede ejecutar este método sobre este recurso. RFC 9110 organiza la semántica HTTP, pero la autorización sigue siendo una decisión local del servicio.

RFC 10025 llama a las cookies autoridad ambiental. El agente de usuario puede adjuntar una credencial a una petición que un tercero indujo sin conocer el secreto. La presencia de la cookie no demuestra intención de la persona. Tampoco su ausencia demuestra una preferencia consciente: puede ser política, ámbito, caducidad o simple expulsión.

El recibo de seis etapas

La primera etapa conserva la respuesta, la hora, las líneas Set-Cookie separadas, la versión de despliegue y una huella que oculta el valor. La segunda registra motor y política de consumo, resultado del análisis y clase de rechazo. La tercera refleja ámbito y banderas normalizados, caducidad efectiva y relación de reemplazo.

La cuarta consigna expiración, borrado, cierre de sesión o expulsión cuando exista visibilidad legítima. La quinta enlaza una petición con URI, método, iniciador, contexto superior, cálculo SameSite e identificadores opacos incluidos o retenidos. La sexta separa análisis del servidor, búsqueda de sesión, autenticación, prueba anti-CSRF, autorización y resultado.

Es una propuesta editorial de Daniel Kade, no un requisito de RFC 10025 ni una interfaz que los navegadores deban publicar. El recibo no contiene valores de cookie, tokens ni secretos. Respeta la jurisdicción del cliente y solo comparte categorías mínimas cuando hay una finalidad y un consentimiento válidos.

La lógica coincide con la prioridad que Heng Lu da al código en ejecución como evidencia. El espejo de políticas debe mostrar el actor y la decisión, no fingir que el servidor controla el almacén ajeno. Ese límite sostiene una cobertura basada en realidad y no en promoción.

Fuentes