Resumen

  • HTTPbis publicó el 9 de septiembre de 2026 la revisión 01 de draft-ietf-httpbis-pre-denied. Es una draft activa del grupo de trabajo, no un RFC ni una asignación aprobada.
  • La versión cambia «Preliminary Request Denied» por Purpose Declined, propone el código 419 y amplía el supuesto a una negativa basada en Sec-Purpose. Fetch solo define hoy el valor prefetch.
  • El origen puede producir la respuesta y también una pasarela que actúe en su nombre. Un proxy independiente no debería hacerlo. La diferencia determina quién puede representar la política del servicio.
  • El código no identifica la regla aplicada. Propongo un registro mínimo que una finalidad, actor, delegación, versión de política, hora, caché y resultado. Es una propuesta editorial de Daniel Kade, no texto normativo de la draft.

De «preliminar» a «finalidad» cambia algo más que el nombre

La historia de la revisión permite ver cómo se movió el problema. La versión 00 usaba un 4xx sin concretar y hablaba de solicitudes preliminares ligadas a prefetch o preload. A las 08:56 UTC del 9 de septiembre, la revisión 01 apareció con el título The Purpose Declined HTTP Status Code, el número propuesto 419 y una formulación que abarca cualquier negativa motivada por la finalidad declarada de la solicitud.

La ficha del Datatracker da al texto una custodia procesal real: documento del grupo HTTPbis, stream IETF, destino Proposed Standard y Tommy Pauly como shepherd. Pero no permite saltar al final del proceso. El estado del IESG es I-D Exists, sin Area Director responsable, procesamiento ni telechat. IANA sigue mostrando 419-420 como no asignados. El número es una decisión de diseño en curso.

La revisión también responde una cuestión menos llamativa y más importante: quién puede generar la respuesta. El origen sí. Un CDN o reverse proxy también, siempre que actúe por cuenta del origen. Un proxy independiente no debería. El verbo no describe capacidad técnica —cualquier intermediario podría fabricar una respuesta— sino legitimidad para atribuir al origen una política de finalidad.

Una pasarela obtiene ese papel de su mandato, no de su posición en la ruta. Si esa relación desaparece de los registros, el operador solo ve una negativa y no puede saber si la originó la aplicación, una regla delegada o una preferencia del tránsito.

La finalidad viaja como dato declarado

Sec-Purpose no es un detector de intenciones. El estándar Fetch lo define para indicar que una petición sirve a un propósito distinto del uso inmediato. Es un campo estructurado y su único token definido en este momento es prefetch. Con esa información, un servidor puede modificar caducidad, negar la precarga o contar la visita de otra forma.

Elegir «Purpose Declined» deja sitio para futuros tokens. No los crea ni amplía por sí mismo las facultades del servidor. El propio texto sostiene que no añade capacidad: rechazar ya era posible. La aportación es que clientes y operadores reciben una categoría reconocible en vez de una negativa genérica.

Esa categoría no prueba lo que una persona quería hacer. Tampoco dice qué módulo originó la solicitud, si hubo consentimiento para actividad en segundo plano o si el cliente describió correctamente su comportamiento. En sentido inverso, el 419 no publica la regla de decisión. Dos servicios pueden contestar igual por motivos muy distintos: economía, carga, geografía, riesgo, tipo de contenido o una excepción que no se cumplió.

El intercambio tiene un alcance preciso: el cliente declara un uso y un actor autorizado manifiesta que lo rechaza por ese motivo. Convertirlo en una condena general del tráfico sería otorgar al encabezado y al código más evidencia de la que contienen.

La delegación debe poder demostrarse sin exponer la política

En una arquitectura distribuida, la respuesta suele nacer lejos del dueño formal de la regla. El CDN decide en el borde antes de consultar a la aplicación. El reverse proxy ejecuta lógica para muchos servicios. Es eficiente, pero crea una pregunta incómoda durante una incidencia: ¿qué autoridad decidió?

No conviene resolverla insertando políticas privadas en el protocolo. La draft advierte que la respuesta puede filtrar estado interno del servidor, y un motivo demasiado específico ampliaría esa exposición. La alternativa es un comprobante operativo limitado, conservado junto a la decisión.

Ese registro debería enlazar el valor exacto de Sec-Purpose; el componente decisor y su función; el origen o tenant que delegó; un identificador estable y la versión de la política; el instante; el resultado; y el tratamiento de caché enviado. Puede añadirse una clase de motivo cuando sea seguro. No hace falta guardar un retrato completo del usuario ni transformar cada petición en expediente.

La finalidad es reproducir una decisión disputada y probar que el gateway actuó dentro del encargo. La topología no basta: estar delante del origen no significa estar autorizado para definir su política.

Una negativa almacenada puede cambiar de dueño

La revisión pide una respuesta sin contenido y ordena descartar cualquier cuerpo recibido. Añade que 419 no es cacheable por heurística y que no debería almacenarse. Este límite protege la dimensión temporal del mandato.

RFC 9110 ofrece compatibilidad: un cliente que desconozca 419 lo interpreta como el miembro x00 de la clase, es decir, como un 4xx genérico. RFC 9111 contiene las reglas generales de almacenamiento. La instrucción específica de la draft evita que una negativa calculada bajo una carga o versión de política determinada se reutilice cuando el contexto ya cambió.

En una pasarela compartida, el error puede ser grave. El objeto cacheado sobrevive al incidente, cruza entre configuraciones o responde a una solicitud cuya finalidad no fue evaluada de nuevo. La respuesta parece venir del origen aunque ninguna autoridad haya tomado esa segunda decisión. Por eso el dato de caché pertenece al registro de mandato, no solo al ajuste de rendimiento.

El diseño más estable mantiene tres capas: semántica mínima en el cable, evidencia interna de quién decidió y política local sobre cuánto explicar al solicitante.

Fuentes