Resumen

  • RFC 2109 normalizó Set-Cookie y Cookie para construir una sesión lógica sobre intercambios HTTP, sin hacerla depender de una conexión persistente.
  • Domain, Path, Max-Age, Secure y el control de caché acotaban la circulación del estado; la norma también exigía control del usuario y restringía cargas automáticas o redirecciones no verificables.
  • Una cookie devuelta acreditaba selección de estado. No acreditaba a la persona presente, consentimiento informado, autorización, vigencia, intención transaccional ni éxito de la aplicación.

La memoria no estaba en la conexión

La RFC 2109 definió una sesión como contexto lógico. Lo dijo de forma expresa: no era una conexión de red persistente, y abrir o cerrar conexiones no debía cambiar el uso de la sesión derivada de cookies. El origen iniciaba con Set-Cookie; el agente de usuario podía continuar con Cookie; cualquiera podía terminar, y Max-Age=0 pedía borrar el estado.

Esta separación evitó que TCP heredara significado comercial. Una conexión viva puede transportar una solicitud con una sesión revocada. Una sesión puede sobrevivir a varias conexiones. Un valor puede persistir en el navegador cuando el servidor ya no lo reconoce. Transporte, custodia local y aceptación de sesión requieren pruebas distintas.

El carrito mostraba el poder y el límite

En el ejemplo, el servidor crea Customer, Part_Number y Shipping. Las reglas de selección hacen que el navegador los devuelva en rutas compatibles. Eso prueba continuidad técnica. No prueba que la persona actual sea el cliente nombrado, que quiera todavía esa mercancía, que pueda autorizar el pago o que la respuesta final signifique una entrega real.

El valor era opaco para el agente de usuario. La aplicación elegía su significado y cualquiera que inspeccionara el encabezado podía leerlo. Domain aplicaba las reglas históricas de alcance; Path seleccionaba prefijos de URI; Max-Age fijaba una vida deseada; Version=1 identificaba el mecanismo. Si coincidían varios Path, el más específico aparecía antes, incluso con nombres repetidos.

Esas propiedades contestaban dónde y cuándo reenviar. No contestaban quién podía decidir. Path no era aislamiento. Domain no convertía todos los servicios relacionados en una misma autoridad.

Secure era una advertencia, no una firma

La redacción de Secure dejaba al agente de usuario determinar qué medio consideraba seguro. El servidor aconsejaba proteger el contenido; el atributo no lo cifraba por sí solo. Tampoco autenticaba al operador del navegador ni vinculaba una acción a un mandato vigente.

La propia sección de seguridad describía el riesgo de lectura y alteración en texto claro. Una cookie podía ser clave de base de datos, estado legible o material falsificado. El servicio debía validar su significado en vez de delegar el juicio a la presencia del campo.

Estado y contenido tomaron caminos diferentes

Separar estado de URL y documento ayudaba a conservar la escala de las cachés. El contenido público podía reutilizarse; el contenido privado de sesión no debía quedarse en una caché compartida. Set-Cookie y la representación necesitaban controles distintos, como private o no-cache="set-cookie". La RFC 2068 aportaba el marco HTTP/1.1 contemporáneo.

Por eso hay que distinguir representación almacenada, encabezado emitido, cookie admitida y sesión aceptada después. Una página pública servida desde caché quizá no llegue al origen que debía iniciar la sesión. Una caché HTTP/1.0 podía conservar Set-Cookie porque no tenía la capacidad moderna de excluir un campo. El rendimiento y la memoria de sesión podían coexistir sólo si sus recibos no se mezclaban.

La reproducción automática ya preocupaba

RFC 2109 llamaba verificable a la transacción cuyo URI podía revisar el usuario. Imágenes integradas y redirecciones automáticas eran ejemplos de transacciones no verificables. La regla intentaba impedir que un origen hiciera comenzar o continuar una sesión con un dominio ajeno sin una oportunidad real de inspección; cualquier excepción debía venir desactivada.

La norma también exigía que el usuario pudiera desactivar envío y almacenamiento, saber si había sesión, examinar valores y decidir persistencia por Domain. Reconocía que el seguimiento podía ser intrusivo aunque la identidad no fuera evidente, y que un formulario posterior podía revelarla.

La RFC 2964 reforzó el lenguaje de consentimiento informado. La RFC 2965 sustituyó RFC 2109 tras experiencia de implementación. La RFC 6265 documentó la práctica desplegada y sus defectos. El texto de revisión de RFC 10025 corresponde a otra etapa. La secuencia documental no demuestra qué ejecutaba un navegador concreto.

La cookie era una etapa de evidencia

El recibo correcto usa verbos separados: el servidor emitió; el navegador admitió; el usuario conservó; el contexto seleccionó; la sesión fue aceptada; la política autorizó; la acción comprometió; el efecto se observó. Un solo Cookie ocupa una etapa, no toda la cadena.

En Running-Code Primacy, Lu Heng exige volver al hecho ejecutable. Minimum Initial Specification reserva las decisiones posteriores al ámbito local. Reality Layers impide que un símbolo suplante a otro nivel de realidad. RFC 2109 creó memoria útil; no creó el veredicto sobre persona, mandato o resultado.

Fuentes